maven 3 profiles.xml replacement?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

maven 3 profiles.xml replacement?

Scott Miller
Hi,

I am trying to upgrade a maven 2.x build system to a maven 3.x build  
system and have run in to a problem with the fact that profiles.xml is  
no longer supported.  Our current build iconfigures the built .ear  
file based on build properties supplied in profiles.xml.  These  
properties are used to configure which features in the application are  
activated based on the client for which the application is being  
built.  It also contains environment specific configuration  
information (database connection info, remote service urls, etc etc).  
We basically created a profiles.xml for each client, and then our  
build server (hudson) had a build track for each deployment which  
would use the correct profile.

Now that profiles.xml is no longer supported, I don't have a place to  
put all of this information.  We have a lot of these profiles files so  
I don't want this information added in to our pom directly.  Modifying  
settings.xml in a hudson build seems like a bad idea, since then if  
multiple hudson builds are run at once, they would impact eachother.

Does anyone have any ideas for how to work around this?

Thanks,

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Wayne Fay
> want this information added in to our pom directly.  Modifying settings.xml
> in a hudson build seems like a bad idea, since then if multiple hudson
> builds are run at once, they would impact eachother.

I don't understand this comment. You should be able to copy all your
profiles into one settings.xml file and then use various activation
options to turn one or another on for a given build.

http://maven.apache.org/settings.html

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Scott Miller
Sorry, I guess I didn't explain.  The configuration settings need to  
be version controlled and the hudson server runs the builds for the  
whole company.

As it stands now, we pull the profiles.xml files from a different svn  
repo and copy them in as part of the hudson build.  I guess we could  
put the settings.xml file for the hudson user in to source control,  
but having all of that information from across all of our projects in  
one place is far from ideal.

-Scott

On Nov 10, 2010, at 7:57 PM, Wayne Fay wrote:

>> want this information added in to our pom directly.  Modifying  
>> settings.xml
>> in a hudson build seems like a bad idea, since then if multiple  
>> hudson
>> builds are run at once, they would impact eachother.
>
> I don't understand this comment. You should be able to copy all your
> profiles into one settings.xml file and then use various activation
> options to turn one or another on for a given build.
>
> http://maven.apache.org/settings.html
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Wayne Fay
> and copy them in as part of the hudson build.  I guess we could put the
> settings.xml file for the hudson user in to source control, but having all
> of that information from across all of our projects in one place is far from

Well, it seems like you have a few options...

1. One big settings.xml file
2. Lots of settings.xml files and use -s parameter to mvn to pick the
right one to use
3. Move all profiles to various pom.xml files
4. Merge or rewrite the old code so Maven3 works with profiles.xml files
5. Stick with Maven2 indefinitely

There are probably other options I haven't considered as well.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Anders Hammar
..or my favorite:
Change to the Maven Way(tm)! What you're doing is not, IMHO, the correct
way. I guess you're not doing Maven deploys to a remote repo as you would
end up with different flavors of a project's artifact? Which can't happen as
releases mustn't change.

What you should do is to either separate each customer build with a
classifier (one project for all customers) or one project for each customer.
In the latter case you would build the "standard" artifact in one project
and then do some kind of overlay in the Maven projects producing the
customer artifacts.

/Anders

On Thu, Nov 11, 2010 at 07:56, Wayne Fay <[hidden email]> wrote:

> > and copy them in as part of the hudson build.  I guess we could put the
> > settings.xml file for the hudson user in to source control, but having
> all
> > of that information from across all of our projects in one place is far
> from
>
> Well, it seems like you have a few options...
>
> 1. One big settings.xml file
> 2. Lots of settings.xml files and use -s parameter to mvn to pick the
> right one to use
> 3. Move all profiles to various pom.xml files
> 4. Merge or rewrite the old code so Maven3 works with profiles.xml files
> 5. Stick with Maven2 indefinitely
>
> There are probably other options I haven't considered as well.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Scott Miller
Thanks for the tips Wayne and Anders.

I think I have two main options:

1.  Use mvn -s with a settings.xml for each config I need.  I didn't  
know this option existed, so thanks for the pointer Wayne.  This lets  
me basically treat my settings.xml as my profiles.xml file.

2.  Modify our build to work like Anders suggests.

I will probably go with option 1 for now and consider option 2 in the  
future.  I am however, not sold on the paradigm of building a web  
application once and committing it to a central repo.  Our web  
applications are in general deployed once, so the need to get the  
artifact from a central repo over and over again pretty much doesn't  
exist.  In general I really believe in the maven way for things that  
can be dependencies of other things.   But, a web app is almost never  
a dependency of another project, so adding it in to the maven repo  
doesn't really do much.

Furthermore, we have 5 tiers (ci, dev, qa, demo, prod) per client.  
Each client has a set of configuration options and each tier needs its  
own specific configuration information (database connections, remote  
service url's, etc).  So the number of total classifiers, or overlay  
projects, would need to be 5 X number of clients.  Then you have to  
add in to the confusion that our integration / selenium tests need to  
run on the final configured artifact.  Right now those tests live in  
the module that builds the ear.  This is natural and allows the built  
artifact to be tested from the project that builds it.  Moving the  
final configuration out to some overlay project would make testing  
less natural.

On a side note, if anyone knows why the profiles.xml file support was  
removed, I would be curious to know the reason.  Local build  
properties are pretty common, and in general putting them in a common  
settings.xml file for all of the maven projects on your computer seems  
weird.  Take the case where I have two projects that need to know  
where the local app server you are deploying to exists.  If both use  
the same property (jboss.home or tomcat.home, or something like that),  
but need to go to different versions of the app server, you have to  
constantly edit your settings.xml to point to the correct global  
jboss.home, or always remember to build with a -P<correct_profile>.  
One build's property configurations shouldn't have to be put in a  
global file.  Local build properties are just a good feature for a  
build system independent of my personal issue on our build machine.

And to end on a positive note, I do like how much faster maven 3 is  
for my builds.  The few I have migrated are all 20% or so faster.

Thanks again for all the help,

Scott


On Nov 10, 2010, at 11:29 PM, Anders Hammar wrote:

> ..or my favorite:
> Change to the Maven Way(tm)! What you're doing is not, IMHO, the  
> correct
> way. I guess you're not doing Maven deploys to a remote repo as you  
> would
> end up with different flavors of a project's artifact? Which can't  
> happen as
> releases mustn't change.
>
> What you should do is to either separate each customer build with a
> classifier (one project for all customers) or one project for each  
> customer.
> In the latter case you would build the "standard" artifact in one  
> project
> and then do some kind of overlay in the Maven projects producing the
> customer artifacts.
>
> /Anders
>
> On Thu, Nov 11, 2010 at 07:56, Wayne Fay <[hidden email]> wrote:
>
>>> and copy them in as part of the hudson build.  I guess we could  
>>> put the
>>> settings.xml file for the hudson user in to source control, but  
>>> having
>> all
>>> of that information from across all of our projects in one place  
>>> is far
>> from
>>
>> Well, it seems like you have a few options...
>>
>> 1. One big settings.xml file
>> 2. Lots of settings.xml files and use -s parameter to mvn to pick the
>> right one to use
>> 3. Move all profiles to various pom.xml files
>> 4. Merge or rewrite the old code so Maven3 works with profiles.xml  
>> files
>> 5. Stick with Maven2 indefinitely
>>
>> There are probably other options I haven't considered as well.
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

jochen-2
In reply to this post by Anders Hammar
On Thu, Nov 11, 2010 at 8:29 AM, Anders Hammar <[hidden email]> wrote:

> Change to the Maven Way(tm)!

That clearly depends on how you define this term. Personally, I don't
see any contradiction between Maven's approach and profile files. In
contrary, I am quite unhappy that they are gone. They have been
incredibly useful for things like having a workspace with multiple
versions of the same software when it comes to things like specifying
database parameters. Using profiles for that is much more complicated,
because I have to explicitly specify the profile with any invocation.

Jochen

--
I Am What I Am And That's All What I Yam (Popeye)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: maven 3 profiles.xml replacement?

Scott Miller
Just so this is on the mailing list so others can benefit from my  
research I plan on trying to use this:

http://mojo.codehaus.org/properties-maven-plugin/usage.html

If it does not work, I will write a plugin that does what I need to  
allow me to pull properties from an external file.  Personally, I  
never used profiles.xml to specify changes to the build process, I  
just used it for build properties.  So this plugin completely replaces  
my previous use of profiles.xml.  Thanks again for the help,

Scott

On Nov 11, 2010, at 4:50 AM, Jochen Wiedmann wrote:

> On Thu, Nov 11, 2010 at 8:29 AM, Anders Hammar <[hidden email]>  
> wrote:
>
>> Change to the Maven Way(tm)!
>
> That clearly depends on how you define this term. Personally, I don't
> see any contradiction between Maven's approach and profile files. In
> contrary, I am quite unhappy that they are gone. They have been
> incredibly useful for things like having a workspace with multiple
> versions of the same software when it comes to things like specifying
> database parameters. Using profiles for that is much more complicated,
> because I have to explicitly specify the profile with any invocation.
>
> Jochen
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Loading...