jira-importer commented on PR #194:
URL:
https://github.com/apache/maven-site-plugin/pull/194#issuecomment-2974825655
Resolve #1141
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific c
jira-importer commented on PR #227:
URL:
https://github.com/apache/maven-site-plugin/pull/227#issuecomment-2974825509
Resolve #1159
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific c
Well, this is the result:
osipovmi@deblndw011x:~/var/Projekte/michael-o/michael-o-parent/target/site
(main =)
$ ll
total 80
drwxr-xr-x 2 osipovmi cad512 2024-09-09 09:34 css/
-rw-r--r-- 1 osipovmi cad 4178 2024-09-09 09:34 dependency-info.html
drwxr-xr-x 2 osipovmi cad512 2024-09-0
Hi,
How does this prevent running the reports for the parent itself?
Konrad
> On 8. Sep 2024, at 09:12, Michael Osipov wrote:
>
> Am 2024-09-06 um 11:06 schrieb Konrad Windszus:
>> Hi,
>> Unlike plugin (with plugin management and its configuration) the reportSet
>> (https://maven.apache.org/re
Am 2024-09-06 um 11:06 schrieb Konrad Windszus:
Hi,
Unlike plugin (with plugin management and its configuration) the reportSet
(https://maven.apache.org/ref/3.9.9/maven-model/maven.html#class_reportSet)
cannot be configured on a POM level which itself should not have the configured
reports.
On
Here's ChatGPT's answer... :-)
To create a common `reportSet` that is applied to all child projects
but not activated in the parent POM itself, you can use a few Maven
techniques, such as creating a profile or leveraging inheritance in a
way that allows the children to inherit the `repo
Hi,
Unlike plugin (with plugin management and its configuration) the reportSet
(https://maven.apache.org/ref/3.9.9/maven-model/maven.html#class_reportSet)
cannot be configured on a POM level which itself should not have the configured
reports.
Once a reportSuite is configured it is active both o
ot;
Verzonden: 10-8-2021 22:18:22
Onderwerp: Re: Commandline inheritance
A git like behavior sound good for me as well.
So install/system-wise < user < project
T
On Tue, Aug 10, 2021, 08:22 Benjamin Marwell wrote:
I read Michaels message the way like option 6:
> Since we have onl
installation (aka global)
> > >
> > > This would fix the naming issue (global becomes global).
> > > Of course this is a breaking change, but for maven 4, this seems
> > > reasonable to me.
> > >
> > > Am So., 8. Aug. 2021 um 11:48
gt; This would fix the naming issue (global becomes global).
> > Of course this is a breaking change, but for maven 4, this seems
> > reasonable to me.
> >
> > Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
> > >
> > > During a discussion with M
ue (global becomes global).
Of course this is a breaking change, but for maven 4, this seems
reasonable to me.
Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
During a discussion with Michael we noticed there's something odd about
the names of some flags and the order of inheritan
e this is a breaking change, but for maven 4, this seems
> reasonable to me.
>
> Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
> >
> > During a discussion with Michael we noticed there's something odd about
> the names of some flags and the order o
asonable to me.
>
> Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte <
> rfscho...@apache.org>:
> >
> > During a discussion with Michael we noticed there's something odd about
> the names of some flags and the order of inheritance.
> >
> > I've tri
breaking change, but for maven 4, this seems
reasonable to me.
Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
>
> During a discussion with Michael we noticed there's something odd about the
> names of some flags and the order of inheritance.
>
> I've tried to
n with Michael we noticed there's something odd about the
> names of some flags and the order of inheritance.
>
> I've tried to explain it on a separate wiki page[1] together with the first 3
> options how we could fix it.
> Please have a look at it and share your thoughts.
Am 2021-08-08 um 11:48 schrieb Robert Scholte:
During a discussion with Michael we noticed there's something odd about the
names of some flags and the order of inheritance.
I've tried to explain it on a separate wiki page[1] together with the first 3
options how we could fix it.
Ple
During a discussion with Michael we noticed there's something odd about the
names of some flags and the order of inheritance.
I've tried to explain it on a separate wiki page[1] together with the first 3
options how we could fix it.
Please have a look at it and share your thought
> On 2018-11-10T16:47:59 +0100
> Hervé BOUTEMY wrote:
>
> > ok, I investigated more in details and added a little trick in [1]:
> > child.site.url.inherit.append.path is inherited independantly from
> > id/name/url
> >
> > this will manage your edge case, which I can understand is expected
> >
On 2018-11-10T16:47:59 +0100
Hervé BOUTEMY wrote:
> ok, I investigated more in details and added a little trick in [1]:
> child.site.url.inherit.append.path is inherited independantly from id/name/url
>
> this will manage your edge case, which I can understand is expected
>
> do you think it i
7;b'-level projects.
>
> it's a corner case just because in b, you define
> distributionManagement.site.id, name and url, but not
> @child.site.url.inherit.append.path: just define this attribute while at it
> (instead of counting on inheritance) and it will work as expected. Li
pth of 'c' spread across all of the
> 'b'-level projects.
it's a corner case just because in b, you define
distributionManagement.site.id, name and url, but not
@child.site.url.inherit.append.path: just define this attribute while at it
(instead of counting on inherita
stic about going through all of those projects
and adding an attribute just to to fix a bug in Maven. :) In my case,
there are over 400 modules at the depth of 'c' spread across all of the
'b'-level projects.
> I can reproduce the issue in an inheritance unit test (n
27;t understand
why, but it is not.
I can reproduce the issue in an inheritance unit test (no-append-urls in
maven-model-builder), but still need to investigate why it does not work as
intended by ModelMerger.mergeSite(...): you can easily check by removing
"name" field in b, you&#x
On 2018-11-04T15:05:19 +
Mark Raynsford wrote:
> On 2018-11-04T15:34:11 +0100
> Hervé BOUTEMY wrote:
>
> > you can build https://github.com/apache/maven/tree/MNG-6059 with quick
> > build
> > instruction at the end of README
> >
>
> Thanks. I've built 523db580468bc2b9d8420470bb24f5f68
On 2018-11-04T15:34:11 +0100
Hervé BOUTEMY wrote:
> you can build https://github.com/apache/maven/tree/MNG-6059 with quick build
> instruction at the end of README
>
Thanks. I've built 523db580468bc2b9d8420470bb24f5f688220701 and it
seems to be working for all but the
project/distributionManag
t; > Seems you found one more thing that I forgot when merging MNG-6059:
> > inheritance of these child.inherit.append.path configurations...
> >
> > I created MNG-6505 [1] and added the fix to MNG-6059 branch.
> >
> > Can you check that it works as you expect? (not
On 2018-11-04T13:34:39 +0100
Hervé BOUTEMY wrote:
> Hi Mark,
>
> Seems you found one more thing that I forgot when merging MNG-6059:
> inheritance of these child.inherit.append.path configurations...
>
> I created MNG-6505 [1] and added the fix to MNG-6059 branch.
>
&g
Hi Mark,
Seems you found one more thing that I forgot when merging MNG-6059:
inheritance of these child.inherit.append.path configurations...
I created MNG-6505 [1] and added the fix to MNG-6059 branch.
Can you check that it works as you expect? (notice: with the new
Let's say I have the following:
4.0.0
com.example
a
1.0.0
pom
https://example.com/a
scm:git:https://example.com/a
scm:git:https://example.com/a
And then:
4.0.0
com.example
a
1.0.0
com.example
b
1.0.0
pom
https://example.com/b
Am 02/02/17 um 00:35 schrieb Christian Schulte:
> Am 02/01/17 um 13:33 schrieb Anders Hammar:
>> I don't understand. Why is this marked as fixed (with no commit reference)
>> if it's on the 3.6.0-candidate list? There have been several similar cases
>> just recently; has there been some incorrect j
Am 02/01/17 um 13:33 schrieb Anders Hammar:
> I don't understand. Why is this marked as fixed (with no commit reference)
> if it's on the 3.6.0-candidate list? There have been several similar cases
> just recently; has there been some incorrect jira update?
>
> /Anders
The issue is not closed. Ju
IRA)
Date: Wed, Feb 1, 2017 at 12:40 AM
Subject: [jira] [Resolved] (MNG-5971) Imported dependencies should be
available to inheritance processing
To: iss...@maven.apache.org
[ https://issues.apache.org/jira/browse/MNG-5971?page=com.
atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ss a release vote.
Am 12/10/16 um 19:58 schrieb schu...@apache.org:
> [MNG-5971] Imported dependencies should be available to inheritance processing
>
> o Updated to remove the system property controlling the feature.
> This introduces the 'include' scope feature and leaves the
&
ated Branches:
> refs/heads/master 814b51661 -> 059b9ab30
>
>
> [MNG-5971] Imported dependencies should be available to inheritance processing
>
> o Updated to warn about conflicting imports in Maven 3.4 and to add the next
> validation level for Maven 3.5 to the A
> >> Updated Branches:
> >> refs/heads/MNG-5871 [created] 48ae9fd4a
> >>
> >> MNG-5871 refactoring: put url extrapolation algorithm in inheritance
> >> model merger
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
e?
>
> Regards,
>
> Hervé
>
> Le jeudi 13 août 2015 00:38:43 hbout...@apache.org a écrit :
>> Repository: maven
>> Updated Branches:
>> refs/heads/MNG-5871 [created] 48ae9fd4a
>>
>>
>> MNG-5871 refactoring: put url extrapolation algorithm in inh
[created] 48ae9fd4a
>
>
> MNG-5871 refactoring: put url extrapolation algorithm in inheritance
> model merger
>
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/48ae9fd4
> Tree: http://git-wip-u
gt;>> inherit from parent
>>>
>>> any idea on a good naming welcome
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> Le samedi 14 juin 2014 21:19:53 Hervé BOUTEMY a écrit :
>>>> yes, seems a good idea:
>>>>
>>
n model missing Version and PublishDate default
>> values
>> Submitted by Michael Osipov .
>>
>>
>> Modified:
>> maven/doxia/doxia-sitetools/trunk/doxia-decoration-model/pom.xml
>>
>> maven/doxia/doxia-sitetools/trunk/doxia-decoration
maven/doxia/doxia-sitetools/trunk/doxia-decoration-model/pom.xml
>
> maven/doxia/doxia-sitetools/trunk/doxia-decoration-model/src/main/java/org/apache/maven/doxia/site/decoration/inheritance/DefaultDecorationModelInheritanceAssembler.java
>
> maven/doxia/doxia-sitetools/
Hello,
I am trying to invoke a single goal before another (ant-based) Mojo
executes.
Due to http://jira.codehaus.org/browse/MNG-5405 I cannot just do
foo:bar in the mojo.xml for the plugin.
So instead, I've defined a lifecycle.xml, with only one goal in it.
This works fine as a workaround for no
Hi again,
just to let you know the issue is DOXIASITETOOLS-65
Thanks a lot in advance for your help!!!
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jan 18, 2012 at 9:31 AM, Simo
Hi Lukas!
thanks for your feedback, I'm filling the issue right now!
All the best, have a nice day,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jan 18, 2012 at 8:49 AM, Lukas Theussl wrot
A quick look at the source code shows that the footer is not taken care
of in doxia-decoration-model's
DefaultDecorationModelInheritanceAssembler. The footer was only
introduced in the last doxia release and this was apparently overlooked.
So the only thing to do is file an issue... :)
-Luk
ping.
sorry guys but I really have the feel that skins release is taking too
much time, if you could provide me some feedbacks I'll proceed to
related actions.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitte
Hi all guys,
I am having troubles with the skin (lst check before re-proposing the
skins releases) and while trying to apply fluido on Apache Commons I
noticed that, attaching a site.xml descriptor to a parent, while the
body.head element is inherited from cildren, body.footer is not.
Did I miss
I have to correct my own email. The behavior here is independent of
relativePath and the presence or absence of modules. As things are
now, a pom like the global asf or maven pom dare not have a site
declared, or it will interact with poms that use it as a parent, even
if those poms fully specify t
I think that there's a general principle at work in MSITE-600, so I
wonder whether anyone else agrees.
Quick summary:
Pom 1 has a distributionManagement/site/url element and a
modules/module element.
Pom 2 has a parent that indicates pom 1, with a relativePath. it also
has a distribution/site/ur
Barrie,
Honestly, the purpose of my email about splitting the list was not to
return attention to this thread :-)
You are correct that my thought process when I wrote that did not take
into account the possibility of sparse checkouts.
What I learned from that thread and other discussions was the
On Sun, Dec 12, 2010 at 10:45 AM, Benson Margulies
wrote:
> On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
> wrote:
>> Benson Margulies wrote:
>>
>>> Say that, in a parent pom, there is an execution of a plugin that sets
>>> a property. (e.g. the build helper plugin's port reserver).
>>>
>>>
there is a problem, maybe this needs to be fixed separately?
When I was investigating the relative link problems with inheritance, I
saw that a hypothetical off-by-one directory-step would lead to links
that actually worked, but would link to the to page of deploy even
though the page itself was
.
Modified:
maven/plugins/trunk/maven-site-plugin/src/it/site-inheritance/aggregator/pom.xml
maven/plugins/trunk/maven-site-plugin/src/it/site-inheritance/module/pom.xml
maven/plugins/trunk/maven-site-plugin/src/it/site-inheritance/parent/pom.xml
maven/plugins/trunk/maven
In my defense, I was busy coding a plugin when I posed the question.
On Sun, Dec 12, 2010 at 5:49 PM, Brett Porter wrote:
> You're probably better using the available plugin expressions for the
> execution root rather than this.
>
> Also, the users@ list is the right place to ask the original qu
You're probably better using the available plugin expressions for the execution
root rather than this.
Also, the users@ list is the right place to ask the original question :)
Cheers,
Brett
On 12/12/2010, at 11:15 AM, Benson Margulies wrote:
> On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
On Sat, Dec 11, 2010 at 7:05 PM, Benjamin Bentmann
wrote:
> Benson Margulies wrote:
>
>> Say that, in a parent pom, there is an execution of a plugin that sets
>> a property. (e.g. the build helper plugin's port reserver).
>>
>> Will those properties inherit down to the children?
>
> No, the runti
Benson Margulies wrote:
Say that, in a parent pom, there is an execution of a plugin that sets
a property. (e.g. the build helper plugin's port reserver).
Will those properties inherit down to the children?
No, the runtime data of project instances is separated.
Benjamin
--
Say that, in a parent pom, there is an execution of a plugin that sets
a property. (e.g. the build helper plugin's port reserver).
Will those properties inherit down to the children?
-
To unsubscribe, e-mail: dev-unsubscr...@mave
gin.inherited.
>
> Considering the three possible values for the inherited field (true != false
> != null), we currently determine the inheritance of an execution based on
>
> inherited = (plugin.execution.inherited != false) && (plugin.inherited !=
> false)
>
> i.e. ex
Hi,
I would appreciate some comments on the above issue MNG-2103 where users
requested that plugin.execution.inherited generally overrides
plugin.inherited.
Considering the three possible values for the inherited field (true !=
false != null), we currently determine the inheritance of an
Okey i'll do that.
Markku
On 20.2.2010 5:10, Jason van Zyl wrote:
Reopen the issue with a sample project expressing the problem. Telling us
something doesn't work without a way to easily reproduce the problem and not
referencing, or updating, the JIRA means there's a good chance we'll never l
Reopen the issue with a sample project expressing the problem. Telling us
something doesn't work without a way to easily reproduce the problem and not
referencing, or updating, the JIRA means there's a good chance we'll never look
at it.
We'll try and be better on our side as well by providing
Hi,
This bug has been marked as fixed but i have defined in parent pom
pluginManagement element the plugin with version, dependencies and
configurations. They are inherited correctly to child pom build element
plugin but everything fails to inherit to plugin in profiles element.
Now i must d
Hi,
I have, based on a question in a forum, reread the documentation about
inheritance in the pom's...
the following information is documented:
--
The packaging type required to be pom for parent and aggregation
(multi-module) projects. These types define the goals bound
> -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> > Stuart McCulloch
> > Sent: Tuesday, September 25, 2007 11:21 AM
> > To: Maven Users List
> > Subject: mojo inheritance
> >
> > Hi,
> >
> >
ed regarding class loaders, but
I'd bet the situation for plugin inheritance is still the same. So you should
be *very* careful with such a functionality.
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
stuff we'll have this with
annotations but doing this with the existing mechanism would be good.
--Brian
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stuart
McCulloch
Sent: Tuesday, September 25, 2007 11:21 AM
To: Maven Users List
Subject: mojo i
Maven Users List
Subject: mojo inheritance
Hi,
I've developed a small plugin that lets you extend mojos from other
maven
plugins by merging the plugin metadata:
http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin/index.h
tml
I've successfully used this to extend various co
Hi guys,
I'm playing a bit with the maven site plugin to see what's left
before it
gets released. However, I have a problem with the site.xml
inheritance when
building multimodule projects: whether I define a site.xml file in
submodules or not, the site plugin always uses the
Hi guys,
I'm playing a bit with the maven site plugin to see what's left before it
gets released. However, I have a problem with the site.xml inheritance when
building multimodule projects: whether I define a site.xml file in
submodules or not, the site plugin always uses the site.
ons from parent classes, but not across projects. With
this, it is e.g. not possible to subclass a "built-in" Maven mojo and
inherit the annotations, or to refactor common Mojo code into a
separate "Base Mojo" project, because the subclass lives in a different
project. Since
code into a
separate "Base Mojo" project, because the subclass lives in a
different
project. Since the annotation inheritance also only looks at parent
classes, it is not possible to have annotated Mojo interfaces,
e.g. for
a Compiler which has different implementations.
To allow
ations from parent classes, but not across projects. With
this, it is e.g. not possible to subclass a "built-in" Maven mojo and
inherit the annotations, or to refactor common Mojo code into a
separate "Base Mojo" project, because the subclass lives in a different
project. Since the a
ommon Mojo code into a
separate "Base Mojo" project, because the subclass lives in a different
project. Since the annotation inheritance also only looks at parent
classes, it is not possible to have annotated Mojo interfaces, e.g. for
a Compiler which has different implementations.
To
:31:45 2007
> New Revision: 552182
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=552182
> Log:
> [MNG-2919] Add fix for depMan scope overwriting to the trunk.
>
> Added:
> maven/components/trunk/maven-project/src/test/java/org/apache/
> maven/project/inh
overwriting to the trunk.
>
> Added:
> maven/components/trunk/maven-project/src/test/java/org/apache/
> maven/project/inheritance/t11/
> maven/components/trunk/maven-project/src/test/java/org/apache/
> maven/project/inheritance/t11/ProjectInheritanceTest.java (with
> props)
>
runk.
Added:
maven/components/trunk/maven-project/src/test/java/org/apache/
maven/project/inheritance/t11/
maven/components/trunk/maven-project/src/test/java/org/apache/
maven/project/inheritance/t11/ProjectInheritanceTest.java (with
props)
maven/components/trunk/maven-project/src/
e the tests :(
Is there a praticular reason that the sslServer dependency is found by
compile or packaging, but not the tests?
My aim is just to compile or run the tests, where the tests of the client
need classes from the sslServer...
--
View this message in context:
http://www.nabble.com/Unit-Tes
ll. I've done several
> > experiments to see if this is possible and have had no success.
> > What would
> > be the appropriate way to enable inheritance of classes in the test
> > hierarchy across modules during the test-compile phase of a multi-pom
> > proje
rom
> classes in
> the test hierarchy across modules in the project, and I'm listing each
> module as a dependency in the parent pom as well. I've done several
> experiments to see if this is possible and have had no success.
> What would
> be the appropriate way to ena
ve done several
experiments to see if this is possible and have had no success.
What would
be the appropriate way to enable inheritance of classes in the test
hierarchy across modules during the test-compile phase of a multi-pom
project? Is such a feature available right now for Maven 2, or
should I
success. What would
be the appropriate way to enable inheritance of classes in the test
hierarchy across modules during the test-compile phase of a multi-pom
project? Is such a feature available right now for Maven 2, or should I
submit a JIRA request?
Thanks,
Jim
that are useful aswell.
-Gisbert
David vicente (JIRA) wrote:
Execution order of report plugins is arbitrary if inheritance is involved
-
Key: MSITE-188
URL: http://jira.codehaus.org/browse/
On 24 Oct 06, at 6:13 AM 24 Oct 06, Graham Leggett wrote:
Hi all,
I have a parent POM, containing the master version number for many
subprojects.
The element, being optional, is left out, and subprojects
inherit the version from the parent.
In the subprojects however, the parent tag is mand
Hi all,
I have a parent POM, containing the master version number for many
subprojects.
The element, being optional, is left out, and subprojects
inherit the version from the parent.
In the subprojects however, the parent tag is mandatory. And despite a
relativePath tag being present pointing b
This is a known issue. You cannot extend a class for which you do not
have the source too, as the annotations are read from the source, not
the binary.
- Brett
On 31/08/2006, at 3:21 AM, Alexis Midon wrote:
Hi all,
I'm developping a custom plugin, its main features already are already
imp
Hi all,
I'm developping a custom plugin, its main features already are already
implemented by the antrun plugin, my only wish is to add an aggregator like
behaviour.
To do so my pojo extends the AntRunMojo, my mojo does nothing except adding
the @aggregator annotation.
Unfortunately when I packa
The sandbox plugins probably don't have relativePath set correctly (it's
not really possible given the checkout structure) so they are getting
the parent from the repository, whereas the others get it from
../pom.xml. I'm guessing the parent hasn't been deployed recently, so
I'll do that now...
From: Edwin Punzalan [mailto:[EMAIL PROTECTED]
Sent: Monday, July 17, 2006 6:18 PM
To: Maven Developers List
Subject: Re: Trying to understand the POM inheritance chain for plugins
Sounds odd, bec both the eclipse and idea plugins are generating 10 of
the project reports in my machine. I even ran
Sounds odd, bec both the eclipse and idea plugins are generating 10 of
the project reports in my machine. I even ran it on javadoc and found
the same 10 reports.
I do agree about the checkstyle plugin being placed inside the pom but
not configured... since its there, we might as well fix an
Hi all
I've been working on a couple of plugins with documentation and
documentation review. One thing differs when running mvn site for a
normal plugin versus a plugin in the sandbox.
For a normal plugin, like maven-javadoc-plugin, you get 4 Project Reports:
* JavaDocs
* Plugin documentation
You need to add the group,arifcatId and version to the
dependencyManagement section of a parent.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of David Smiley
Sent: Tuesday, May 09, 2006 4:19 PM
To: m2-dev@maven.apache.org
Subject: inheritance
http://maven.apache.org
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
At the above page, there is an example of modules specifying
dependencies without a version. The version is fully specified by the
parent. Okay, that's nice. But it just doesn't work for me. I get
these e
Brett Porter wrote:
Can we get unit tests for these types of changes?
I think we decided coverage should not go down. How about we activate
coverage testing and get the build to fail when it drops. We all need
the reminder because we've all let it drop.
Jason.
ing '..' path adjustments.
>
> Modified:
>
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/inheritance/DefaultModelInheritanceAssembler.java
>
> Modified:
> maven/components/trunk/maven-project/src/main/java/org/apache/maven/project
[ http://jira.codehaus.org/browse/MNG-2068?page=all ]
John Casey updated MNG-2068:
Assign To: John Casey
Fix Version: 2.0.3
> Multiple inheritance fails to find "grand" parent in ../../pom.xml when the
> groupIds differ (Te
[ http://jira.codehaus.org/browse/MNG-2068?page=all ]
John Casey closed MNG-2068:
---
Resolution: Fixed
confirmed fixed by Brian Fox...I added a variant of good-sample.zip as it0097.
> Multiple inheritance fails to find "grand" parent in ../..
it
from coming back.
> Multiple inheritance fails to find "grand" parent in ../../pom.xml when the
> groupIds differ (Test Case Attached)
>
>
> Key
[ http://jira.codehaus.org/browse/MNG-2103?page=all ]
Yann Le Du updated MNG-2103:
Attachment: test-inheritance-true.zip
> Inheritance of overrides that of
> -
>
> Key: MNG-2103
&g
[ http://jira.codehaus.org/browse/MNG-2103?page=comments#action_59250 ]
Prasad Kashyap commented on MNG-2103:
-
I see what you mean. That makes sense only if the is set to
false.
Now flip the inheritance boolean at the level to true. Going by the
on't even exist. What do you think ?
You can visualize that by running mvn help:effective-pom in parent project.
> Inheritance of overrides that of
> -
>
> Key: MNG-2103
> URL: http://jira.codehaus.org/brow
1 - 100 of 363 matches
Mail list logo
