Hi,
I have a requirement where I need to specify specific versions for a
set of (basic) plugins. Adding the versions to the pom isn't an option
because we need to set the plugin versions for a vast number of
_unrelated_ builds.
As I've found at [1], I've manually created a plugin-registry.xml file
Hi,
We are facing an issue with projects using resource filtering with m-assembly-p
(filtering=true in a fileset). m-assembly-p always use default platform
encoding to do filtering. It seems this plugin was forgotten during
introduction of project.build.sourceEncoding property [1].
I have
I don't know about plugin-registry.xml, but you can distribute a
settings.xml for use with -gs that has an active-by-default profile
with a pluginManagement section that does the job.
On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote:
Hi,
I have a requirement where I
Why not define the pluginDependency section in a parent pom, then each of
your projects uses this as a parent, and pulls in all the plugin dep
versions defined in it (or overrides in project pom if necessary). Seems
that would be simplest solution
Damian
On Mon, Jul 25, 2011 at 7:43 AM, Benson
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
dbradic...@sonatype.comwrote:
Why not define the pluginDependency section in a parent pom, then each of
your projects uses this as a parent, and pulls in all the plugin dep
versions defined in it
On 25 Jul 2011, at 17:13, Benson Margulies bimargul...@gmail.com
wrote:
I don't know about plugin-registry.xml, but you can distribute a
settings.xml for use with -gs that has an active-by-default profile
with a pluginManagement section that does the job.
Benson,
That would do the job
On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
dbradic...@sonatype.com wrote:
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
dbradic...@sonatype.comwrote:
Why not define the pluginDependency section in a parent pom, then each of
your
I'm looking at this now. Thanks.
On 7/25/11 3:27 AM, Julien HENRY wrote:
Hi,
We are facing an issue with projects using resource filtering with m-assembly-p
(filtering=true in a fileset). m-assembly-p always use default platform
encoding to do filtering. It seems this plugin was forgotten
But why ? simply have a top level parent pom that is solely for defining
your plugin versions (and anything else that may cover all of your
projects), you don't need any project specific logic in there. The parent
doesn't need to list any of the children that use it (and act as an
aggregator),
On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
dbradic...@sonatype.com wrote:
But why ? simply have a top level parent pom that is solely for defining
your plugin versions (and anything else that may cover all of your
projects), you don't need any project specific logic in there. The
As a general principle, the design of maven is trending toward locking
down the versions of plugins for a build. Otherwise, you can't grab an
old version of the source from a tag and depend on building it.
Therefore, the idea of a separate 'control panel' for plugin versions
is not popular.
I'm still not seeing the problem, certainly a specific release of a parent
pom would be static, but if you need to update versions, you update the pom
and release a new version, then update your projects to use it as necessary.
It is a simple workflow, and leaves a single place where all versions
On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies bimargul...@gmail.com wrote:
As a general principle, the design of maven is trending toward locking
down the versions of plugins for a build. Otherwise, you can't grab an
old version of the source from a tag and depend on building it.
On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich
dbradic...@sonatype.com wrote:
I'm still not seeing the problem, certainly a specific release of a parent
pom would be static, but if you need to update versions, you update the pom
and release a new version, then update your projects to use it
A thought: since 'extensions' has no 'management' or inheritance
control, the use of it is actually harder and more obscure when people
want to use other versions. It's far easier to just manage
dependencies of the site plugin via pluginManagement. So, I'm in favor
of using and documenting
15 matches
Mail list logo
