Pattern to setup common organization specific data in single pom?

[Oskar Carlstedt <os...@gmail.com>]

Hello?

I wonder if there is any pattern in Maven defining how to setup common
organization specific data. What I mean is that I only want to define my
distribution management in one place, I only want to setup specific deploy
paths in one place etc., etc.

One way is to define a lot of properties in a settings.xml - but then the
user has to define all these properties himself. When properties are
changing, then we have a mess. Even worse, there is no version tracking of
properties using this solution.  That is not good enough.

One other way would be to use a global parent. Going that way it is possible
to inherit all common data. But the disadvantage is that I cannot change the
values without updating the same version of the parent in the repository
(because Maven does not manage to resolve version ranges for the parent
pom).

So, is there any other suggestions? Can I import the data using version
scopes. I like to be able to define exact versions of what I include in my
builds but when it comes to build/deploy specific data, then I would like to
be able to change this for all users in one place. 

Any advice to solve this problem is really appreciated!
Cheers,
Oskar


-- 
View this message in context: http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26723137.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: Pattern to setup common organization specific data in single pom?

[Anders Hammar <an...@hammar.net>]

Just to be clear, when you say "version scope" do you mean version range?

What you could do is to use a property for some elements in your pom. The
default value is defined in the pom through defining the property. It is
then possible for each user to override this, either through their
settings.xml or the command line. Have a look at the Apache parent pom I
linked to earlier:
http://repo2.maven.org/maven2/org/apache/apache/6/apache-6.pom
In that pom this technique is used for the url of the snapshot repo of their
distribution management.

However, I agree that there are some elements of the pom that one could
think shouldn't be "locked down" for a release. However, often there's a
wider concept like with the scm part. The scm info in the pom of a release
artifact can be used to retrieve that exact project. Very useful for open
source projects where a lot of people are interested in quickly getting
them. The benefit of not having to trying to find this info on the home page
is not to ignore. So, do change them! :-) Or, at least make sure that the
old url continue to work for released artifacts (the importance of this
depends on the size of your audience).

Regarding having to "walk through all POMs that are using that value" I'd
argue that the benefit of having the value defined in a parent pom means you
don't have to traverse every pom updating the old value. As you clearly
understand the concepts I think I'm missing something to the story here...

Regarding the settings.xml it would be very interesting to hear about some
success story using the global settings.xml for corp wide stuff and the
personal one just for passwords etc. How do you go about doing this in an
agile, lightweight way? As the global settings.xml is part of the Maven
installation, it will be replaced whenever a new Maven version is installed.
This would either require a centrally re-package Maven bin or some tool for
always keeping this file updated. I have always kept away from the global
one for these reason. Any best-practice solution anyone can share?

/Anders

On Fri, Dec 11, 2009 at 07:46, Oskar Carlstedt <os...@gmail.com>wrote:

>
> Hello all of you!
>
> Thank for your replies. I've tested all strategies told here, except for
> using a plugin generating the settings.xml, in earlier projects. I never
> had
> the feeling feeling of hitting the big success. Maybe the plugin way will
> work.
>
> I can understand all arguments for not being able to change the pom after a
> release, and therefore all arguments of not having a version scope on the
> parent pom. For me this applies to all build logic, but not for
> distribution
> management, deploy management etc., etc. This is the case where I want to
> be
> able to change some settings, not changing the build itself.
>
> Let say we change the url to our SCM, then we have to change all POMs
> configured using the old SCM. This mitgh be a network problem, but still
> such things happens.
>
> Let say I change the URL to the location of my globally published WSDL
> files
> or other resources. Then it is a must to walk through all POMs that are
> using that value.
>
> Ok, in booth cases above I can put expected data into the settings.xml
> file.
> I don't like this way because I think settings.xml is the user's personal
> file and it does not have the purpose of holding default values. Further,
> all settings had during a build is not checked in during a release because
> these vales are put in the settings.xml file. But it might be the only way
> to go. So having a plugin generating the most up to date settings.xml file
> might be a good way finding the path to the big success.
>
> Maybe we shall vote for a extra feature in the release plugin that makes it
> possible to checkin the current settings.xml and the full build log when
> doing a release. Just to get the full trace of a build.
>
>
> Thank you all again for your answers!
> Cheers,
> Oskar
>
>
>
> --
> View this message in context:
> http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26739437.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: Pattern to setup common organization specific data in single pom?

[Oskar Carlstedt <os...@gmail.com>]

Hello all of you!

Thank for your replies. I've tested all strategies told here, except for
using a plugin generating the settings.xml, in earlier projects. I never had
the feeling feeling of hitting the big success. Maybe the plugin way will
work.

I can understand all arguments for not being able to change the pom after a
release, and therefore all arguments of not having a version scope on the
parent pom. For me this applies to all build logic, but not for distribution
management, deploy management etc., etc. This is the case where I want to be
able to change some settings, not changing the build itself.

Let say we change the url to our SCM, then we have to change all POMs
configured using the old SCM. This mitgh be a network problem, but still
such things happens.

Let say I change the URL to the location of my globally published WSDL files
or other resources. Then it is a must to walk through all POMs that are
using that value.

Ok, in booth cases above I can put expected data into the settings.xml file.
I don't like this way because I think settings.xml is the user's personal
file and it does not have the purpose of holding default values. Further,
all settings had during a build is not checked in during a release because
these vales are put in the settings.xml file. But it might be the only way
to go. So having a plugin generating the most up to date settings.xml file
might be a good way finding the path to the big success.  

Maybe we shall vote for a extra feature in the release plugin that makes it
possible to checkin the current settings.xml and the full build log when
doing a release. Just to get the full trace of a build.


Thank you all again for your answers!
Cheers,
Oskar



-- 
View this message in context: http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26739437.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: Pattern to setup common organization specific data in single pom?

[Anders Hammar <an...@hammar.net>]

I'd say the Maven way is to keep this info/data in a corp parent. For
instance, have a look how this is done at Apache:
http://repo1.maven.org/maven2/org/apache/apache/6/apache-6.pom
As you can see, some values are handled by properties which make them
customizable by projects using this parent.

You should never, never change the info in a released artifact (a corp
parent pom for instance). Instead, increment the version and do the
necessary changes. I see this as an advantage and not a disadvantage.

If you want to make sure that all projects are using the latest and greatest
corp parent, that should be possible to enforce by an appropriate rule and
the enforcer plugin.

/Anders

On Thu, Dec 10, 2009 at 08:34, Oskar Carlstedt <os...@gmail.com>wrote:

>
> Hello?
>
> I wonder if there is any pattern in Maven defining how to setup common
> organization specific data. What I mean is that I only want to define my
> distribution management in one place, I only want to setup specific deploy
> paths in one place etc., etc.
>
> One way is to define a lot of properties in a settings.xml - but then the
> user has to define all these properties himself. When properties are
> changing, then we have a mess. Even worse, there is no version tracking of
> properties using this solution.  That is not good enough.
>
> One other way would be to use a global parent. Going that way it is
> possible
> to inherit all common data. But the disadvantage is that I cannot change
> the
> values without updating the same version of the parent in the repository
> (because Maven does not manage to resolve version ranges for the parent
> pom).
>
> So, is there any other suggestions? Can I import the data using version
> scopes. I like to be able to define exact versions of what I include in my
> builds but when it comes to build/deploy specific data, then I would like
> to
> be able to change this for all users in one place.
>
> Any advice to solve this problem is really appreciated!
> Cheers,
> Oskar
>
>
> --
> View this message in context:
> http://old.nabble.com/Pattern-to-setup-common-organization-specific-data-in-single-pom--tp26723137p26723137.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: Pattern to setup common organization specific data in single pom?

[Anders Hammar <an...@hammar.net>]

There are also solutions with a maven plugin downloading and installing
settings.xml. Such a plugin is included in Nexus Pro, but it shouldn't be
too hard to write yourself (or is there an oss version already?).

/Anders

On Thu, Dec 10, 2009 at 16:35, Wayne Fay <wa...@gmail.com> wrote:

> > One way is to define a lot of properties in a settings.xml - but then the
> > user has to define all these properties himself. When properties are
> > changing, then we have a mess. Even worse, there is no version tracking
> of
> > properties using this solution.  That is not good enough.
>
> I've heard of many organizations who check in their settings.xml file
> into their SCM, making distributing and updating it pretty much dead
> simple.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Pattern to setup common organization specific data in single pom?

[Wayne Fay <wa...@gmail.com>]

> One way is to define a lot of properties in a settings.xml - but then the
> user has to define all these properties himself. When properties are
> changing, then we have a mess. Even worse, there is no version tracking of
> properties using this solution.  That is not good enough.

I've heard of many organizations who check in their settings.xml file
into their SCM, making distributing and updating it pretty much dead
simple.

Wayne

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