> 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 documentin
On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich
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 as necessary.
> It i
On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies 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.
>
> Therefore, the idea of a
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
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. Global
On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
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 parent
> doesn't need to l
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), th
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 dur
On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
wrote:
> err...pluginManagement section even ;)
>
> Damian
>
> On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
> wrote:
>
>> Why not define the pluginDependency section in a parent pom, then each of
>> your projects uses this as a parent, and pul
On 25 Jul 2011, at 17:13, Benson Margulies
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 though that's not exactl
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
wrote:
> 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 proj
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 M
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 wrote:
> Hi,
> I have a requirement where I need to specify spe
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 writ
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
15 matches
Mail list logo
