You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Raketemensch <li...@libertylost.org> on 2012/05/07 21:55:08 UTC

Best way to handle a universal pom?

When we were working with Ant, we created a build.xml file that had generic
targets that we needed in every build. This allowed us to change a single
file once, and have all 300+ builds be instantly updated.

I'd like to do the same thing with Maven, but am concerned about creating
dependency issues, so I thought I would find out what would be the most
recommended way to go about doing it.

Take profiles, for instance -- we use Wagon for SCPing files out to the
servers, so we have a profile set up for each environment (dev, qa, test,
prod, etc) that we currently include in every ear pom. 

Ideally we could just include these profiles in a single pom.xml and include
it in all the projects. Opinions on the best way to do so?


Thanks,
Rake

--
View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by Stephen Connolly <st...@gmail.com>.
http://svn.codehaus.org/mojo/trunk/mojo/ship-maven-plugin/src/it/plugin-deps/

is the closest to an example I have at this time.

It would be great if you could turn that into a patch for the plugin
docs to explain how it works

On 15 May 2012 21:18, Raketemensch <li...@libertylost.org> wrote:
> Sorry for the delayed response.... Thank you, that's awesome.
>
> Do you have an example of how it would work? The Maven site for the plugin
> makes reference to "wagon scripts," but the only wagon stuff I've seen is
> added to an existing pom file. If there's a way to extract the wagon stuff
> and the profile info, I'd be forever in your debt.
>
> Just this morning I released 5 projects to production, one of which was
> missing the prod profile info. Sucks to discover at 7am in a prod release
> window, yaknow? So being able to set this stuff globally is pretty much the
> ideal way for releasing tons of projects in an large enterprise environment.
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5708795.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by Raketemensch <li...@libertylost.org>.
Sorry for the delayed response.... Thank you, that's awesome.

Do you have an example of how it would work? The Maven site for the plugin
makes reference to "wagon scripts," but the only wagon stuff I've seen is
added to an existing pom file. If there's a way to extract the wagon stuff
and the profile info, I'd be forever in your debt.

Just this morning I released 5 projects to production, one of which was
missing the prod profile info. Sucks to discover at 7am in a prod release
window, yaknow? So being able to set this stuff globally is pretty much the
ideal way for releasing tons of projects in an large enterprise environment.

--
View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5708795.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by Stephen Connolly <st...@gmail.com>.
I think I have made the modifications that would make your life
simpler... you probably still would need to change a parent pom, but
that would be the only change... fix will be in ship-maven-plugin
1.0-alpha-2

On 10 May 2012 09:39, Stephen Connolly <st...@gmail.com> wrote:
> Hmmm. I wonder if I were to modify the ship-maven-plugin to allow ship
> scripts to be pulled from the plugin's classpath rather than the
> filesystem would that solve your issue.
>
> On 9 May 2012 21:49, Raketemensch <li...@libertylost.org> wrote:
>> Well, that's why I'm asking for a best practice, I'm trying to avoid
>> antishness as much as possible.
>>
>> However, I'm in charge of 400+ individual Maven projects, not counting all
>> the modules. If an environment changes, I'm not eager to load up 400+
>> individual pom files to make the required change, then commit them all, etc.
>>
>> The profiles I'm looking to include look like this:
>>
>> <profile>
>>                        <id>iwebdev</id>
>>                        <build>
>>                                <plugins>
>>                                        <plugin>
>>                                                <groupId>org.codehaus.mojo</groupId>
>>                                                <artifactId>wagon-maven-plugin</artifactId>
>>                                                <version>1.0-beta-3</version>
>>                                                <executions>
>>                                                        <execution>
>>                                                                <id>iwebdev05</id>
>>                                                                <phase>deploy</phase>
>>                                                                <goals>
>>                                                                        <goal>upload-single</goal>
>>                                                                </goals>
>>                                                                <configuration>
>>                                                                        <serverId>iwebdev05</serverId>
>>                                                                        <fromFile>${project.build.directory}/${final.name}.ear</fromFile>
>>                                                                        <url>scp://iwebdev05/data/web/webapps</url>
>>                                                                </configuration>
>>                                                        </execution>
>>                                                        <execution>
>>                                                                <id>iwebdev06</id>
>>                                                                <phase>deploy</phase>
>>                                                                <goals>
>>                                                                        <goal>upload-single</goal>
>>                                                                </goals>
>>                                                                <configuration>
>>                                                                        <serverId>iwebdev06</serverId>
>>                                                                        <fromFile>${project.build.directory}/${final.name}.ear</fromFile>
>>                                                                        <url>scp://iwebdev06/data/web/webapps</url>
>>                                                                </configuration>
>>                                                        </execution>
>>
>>                                                </executions>
>>                                        </plugin>
>>                                </plugins>
>>                        </build>
>>                </profile>
>>
>> It's not something I can put into a settings.xml file, which I'd rather not
>> do anyway, since it would be a very big potential build-breaker. But at the
>> same time, we have 10+ individual environments, and I'd rather not pollute
>> each project pom with pages of this stuff, nor would I like to (As mentioned
>> earlier) update 400+ poms just because a server path changes.
>>
>> Is there a better way to handle this?
>>
>> (I appreciate any advice given)
>>
>> --
>> View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5698492.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Best way to handle a universal pom?

Posted by Stephen Connolly <st...@gmail.com>.
Hmmm. I wonder if I were to modify the ship-maven-plugin to allow ship
scripts to be pulled from the plugin's classpath rather than the
filesystem would that solve your issue.

On 9 May 2012 21:49, Raketemensch <li...@libertylost.org> wrote:
> Well, that's why I'm asking for a best practice, I'm trying to avoid
> antishness as much as possible.
>
> However, I'm in charge of 400+ individual Maven projects, not counting all
> the modules. If an environment changes, I'm not eager to load up 400+
> individual pom files to make the required change, then commit them all, etc.
>
> The profiles I'm looking to include look like this:
>
> <profile>
>                        <id>iwebdev</id>
>                        <build>
>                                <plugins>
>                                        <plugin>
>                                                <groupId>org.codehaus.mojo</groupId>
>                                                <artifactId>wagon-maven-plugin</artifactId>
>                                                <version>1.0-beta-3</version>
>                                                <executions>
>                                                        <execution>
>                                                                <id>iwebdev05</id>
>                                                                <phase>deploy</phase>
>                                                                <goals>
>                                                                        <goal>upload-single</goal>
>                                                                </goals>
>                                                                <configuration>
>                                                                        <serverId>iwebdev05</serverId>
>                                                                        <fromFile>${project.build.directory}/${final.name}.ear</fromFile>
>                                                                        <url>scp://iwebdev05/data/web/webapps</url>
>                                                                </configuration>
>                                                        </execution>
>                                                        <execution>
>                                                                <id>iwebdev06</id>
>                                                                <phase>deploy</phase>
>                                                                <goals>
>                                                                        <goal>upload-single</goal>
>                                                                </goals>
>                                                                <configuration>
>                                                                        <serverId>iwebdev06</serverId>
>                                                                        <fromFile>${project.build.directory}/${final.name}.ear</fromFile>
>                                                                        <url>scp://iwebdev06/data/web/webapps</url>
>                                                                </configuration>
>                                                        </execution>
>
>                                                </executions>
>                                        </plugin>
>                                </plugins>
>                        </build>
>                </profile>
>
> It's not something I can put into a settings.xml file, which I'd rather not
> do anyway, since it would be a very big potential build-breaker. But at the
> same time, we have 10+ individual environments, and I'd rather not pollute
> each project pom with pages of this stuff, nor would I like to (As mentioned
> earlier) update 400+ poms just because a server path changes.
>
> Is there a better way to handle this?
>
> (I appreciate any advice given)
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5698492.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Re: Best way to handle a universal pom?

Posted by Raketemensch <li...@libertylost.org>.
Well, that's why I'm asking for a best practice, I'm trying to avoid
antishness as much as possible.

However, I'm in charge of 400+ individual Maven projects, not counting all
the modules. If an environment changes, I'm not eager to load up 400+
individual pom files to make the required change, then commit them all, etc.

The profiles I'm looking to include look like this:

<profile>
			<id>iwebdev</id>
			<build>
				<plugins>
					<plugin>
						<groupId>org.codehaus.mojo</groupId>
						<artifactId>wagon-maven-plugin</artifactId>
						<version>1.0-beta-3</version>
						<executions>
							<execution>
								<id>iwebdev05</id>
								<phase>deploy</phase>
								<goals>
									<goal>upload-single</goal>
								</goals>
								<configuration>
									<serverId>iwebdev05</serverId>
									<fromFile>${project.build.directory}/${final.name}.ear</fromFile>
									<url>scp://iwebdev05/data/web/webapps</url>
								</configuration>
							</execution>
							<execution>
								<id>iwebdev06</id>
								<phase>deploy</phase>
								<goals>
									<goal>upload-single</goal>
								</goals>
								<configuration>
									<serverId>iwebdev06</serverId>
									<fromFile>${project.build.directory}/${final.name}.ear</fromFile>
									<url>scp://iwebdev06/data/web/webapps</url>
								</configuration>
							</execution>

						</executions>
					</plugin>
				</plugins>
			</build>
		</profile>

It's not something I can put into a settings.xml file, which I'd rather not
do anyway, since it would be a very big potential build-breaker. But at the
same time, we have 10+ individual environments, and I'd rather not pollute
each project pom with pages of this stuff, nor would I like to (As mentioned
earlier) update 400+ poms just because a server path changes.

Is there a better way to handle this?

(I appreciate any advice given)

--
View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5698492.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by Anders Hammar <an...@hammar.net>.
You need to do this in a parent pom. But, I'd like to stress what
you're trying to do is not Maven-ish. Maven is not Ant, you need to
forget how you did things with Ant and think differently.

/Anders

On Wed, May 9, 2012 at 10:18 PM, Raketemensch <li...@libertylost.org> wrote:
> I have tried creating a pom that lists the profiles, publishing it, then
> declaring it as a dependency on a few of the builds for testing, but it
> appears that profiles are not one of the things inherited from dependent
> poms....
>
> I'm back to the drawing board on how to get this to work.
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5698418.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by Raketemensch <li...@libertylost.org>.
I have tried creating a pom that lists the profiles, publishing it, then
declaring it as a dependency on a few of the builds for testing, but it
appears that profiles are not one of the things inherited from dependent
poms....

I'm back to the drawing board on how to get this to work.

--
View this message in context: http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958p5698418.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Best way to handle a universal pom?

Posted by mike digioia <mp...@gmail.com>.
This is what I would like to do but did not know what to expect, since so
much more understanding of Maven would first need to be known to start, Is
it possible? If so what potential issues?

On Mon, May 7, 2012 at 12:55 PM, Raketemensch <li...@libertylost.org> wrote:

> When we were working with Ant, we created a build.xml file that had generic
> targets that we needed in every build. This allowed us to change a single
> file once, and have all 300+ builds be instantly updated.
>
> I'd like to do the same thing with Maven, but am concerned about creating
> dependency issues, so I thought I would find out what would be the most
> recommended way to go about doing it.
>
> Take profiles, for instance -- we use Wagon for SCPing files out to the
> servers, so we have a profile set up for each environment (dev, qa, test,
> prod, etc) that we currently include in every ear pom.
>
> Ideally we could just include these profiles in a single pom.xml and
> include
> it in all the projects. Opinions on the best way to do so?
>
>
> Thanks,
> Rake
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Best-way-to-handle-a-universal-pom-tp5691958.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>