Yeah, that's what made me think about combining them.
Brett Porter wrote:
On 05/05/2009, at 10:16 AM, Brian Fox wrote:
Why crawl the repo a second time? Tamas has code to generate the
archetype data directly from the index.
True. Is there a way for the indexer to generate it during
ClassCastExceptions at
runtime or sue type-safe collections to help them create stronger
code ?Anyway,
few plugins allready use Java5. Java 1.4 based one will not be
broken as the
generics signature is only a compile-time check.
2009/5/1 Brian Fox bri...@infinity.nu
I'm not sure if this is in scope
I'm not sure if this is in scope of what John is trying to do wrt to 2.2.
Jason van Zyl wrote:
I don't believe anyone actually agreed to this yet. Are you sure this
is not going to cause problems for users?
On 1-May-09, at 1:04 AM, nico...@apache.org wrote:
Author: nicolas
Date: Fri May 1
I've promoted these artifacts to the release repository.
Brian Fox wrote:
This vote now has sufficient votes to pass. However some concerns were
raised on legal-discuss (apparently a month ago and not mentioned
here) that may require some tweaks to the release profile. I'll hold
on promoting
Brian Fox bri...@infinity.nu:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/ap
ache/apache/6/apache-6.pom
https://repository.apache.org/content/repositories/maven-staging-012/org/apa
che/maven/maven-parent/12
We already decided to move to 1.5 in 2.1 but never did. For me it's a
given in 2.2, why even bother debating it?
John Casey wrote:
Read MNG-4140. We had a solution much like you mention (it used string
searches, not DOM searches, but amounts to the same thine...the
version element is
Besides inertial friction to a change, is there a specific reason not to
consolidate on a single http provider? We already know that people may
use the dav wagon simply to handle larger artifacts and such, it seems
like reducing our surface area here would help
I wouldn't be opposed to
Anyone else? We have just two votes so far.
On 4/20/2009 11:05 PM, Brian Fox wrote:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/apache/apache/6/apache-6.pom
https://repository.apache.org/content/repositories/maven
I'm talking with the jgit guys to see about adapting the git archive
functionality to implement an effective export that we can use from the
release plugin. Mark, it looks like the git provider is already setup to
easily integrate an alternate implementation so I think this won't be
hard once
If you like me to help then simply ping me, I'd be honoured to help.
I didn't dive into the testing structure in place there, but if it
doesn't exist already, some external ITs would be awesome. Something we
could run against the multiple implementations to guarantee compatibility.
Svn is up again it seems so you can login to Nexus if you want to look.
On 4/24/2009 1:40 AM, Brett Porter wrote:
Can't access these since Nexus is not responding because SVN is down.
My vote is on the ones in SVN, I'm going to trust they are the same.
+1
On 21/04/2009, at 1:05 PM, Brian Fox
because people _can_
rebase/resync their local repo clone doesn't mean they _have to_. Code
in different repo clones could diverge pretty wildly. In particular,
I'm thinking about Don Brown's maven builds, only magnified.
Just some thoughts.
-john
Brian Fox wrote:
2) On a more serious note
On the release plugin I believe John Smart has that working. And
having our release toolchain tested before switching is a completely
reasonable criterion.
That's my primary concern, that the tools support it, or we experiment
first to find out _how_ they work. It seems like from the
Mark Struberg wrote:
technically there is no git repo which is 'better' than the other.
This hierarchy is an orga one.
If you can pull from my repo and from Jasons, from whom will you pull your
master mainly? Bet you will pull from Jasons. And I also bet all contributors
will try to get
Agreed 100%, it applies across the board. We have two hurdles, one easy,
one not so easy:
1. fix the release plugin / scm provider.
2. convince infra to host a rw git repo.
Tim O'Brien wrote:
I think DVCS would benefit Maven doc. Someone (not a commiter) could clone
the site, fix it,
Isn't Nicolas around, maybe he'd like to offer a translation?
Jason van Zyl wrote:
Thanks if that seems like a reasonable translation I will respond.
On 23-Apr-09, at 4:00 PM, Christian Edward Gruber wrote:
My french isn't perfect, but the article basically...
summary
...argues against you
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix the
other stuff, great. But lets keep the scope very small and limited so we
can get the regressions in 2.1.0 out quickly. I'm afraid that relabeling
it 2.2 would mean a pile on the bandwagon effect occurs and we'd be
stuck
FWIW, here might have been a good place to discuss concerns to begin
with, instead of on a blog.
Brian Fox wrote:
Isn't Nicolas around, maybe he'd like to offer a translation?
Jason van Zyl wrote:
Thanks if that seems like a reasonable translation I will respond.
On 23-Apr-09, at 4:00 PM
2) On a more serious note: this is EXACTLY the issue. Jason is no more
special than I am or anyone else on the Maven PMC. That is why there is a
centralized storage for the repo. Anyone on the PMC (actually, any
committer) MUST have access to entire repo for the project and be able to do
On 4/23/2009 9:57 PM, Brett Porter wrote:
On 24/04/2009, at 9:55 AM, Brian Fox wrote:
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix the
other stuff, great. But lets keep the scope very small and limited so
we can get the regressions in 2.1.0 out quickly.
I don't think
or in settings.xml, it will just prompt you for
the passphrase. Thus, it's not needed in the config.
Dan
On Mon April 20 2009 11:05:50 pm Brian Fox wrote:
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/a
pache/apache/6/apache-6.pom
It definately sounds strange to me, but without debugging through that
code it's hard to say for sure.
Stephen Connolly wrote:
Bump!
Brett, Jason, Benjamin, Brian, anyone?
-Stephen
2009/4/21 Stephen Connolly stephen.alan.conno...@gmail.com
mailto:stephen.alan.conno...@gmail.com
Came
it explicitelytherefore if people have their own existing
release profiles, it's probably better that we don't stomp on them.
Jochen Wiedmann wrote:
On Tue, Apr 21, 2009 at 5:05 AM, Brian Fox bri...@infinity.nu wrote:
projects to produce proper releases. I think to do it and avoid conflicts
+1
Paul Gier wrote:
I still need on more vote on this before I can release it.
So far we have:
+1 (binding): John Casey, Benjamin Bentmann
Thanks!
Paul Gier wrote:
Hi,
We solved 10 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147styleName=Htmlversion=13830
There
That was an error, I'll roll it back.
Dennis Lundberg wrote:
Brian, why are you modifying the pom.xml file under the apache-5 tag?
That has already been released and shouldn't be tampered with...
bri...@apache.org wrote:
Author: brianf
Date: Tue Apr 21 01:55:16 2009
New Revision: 766940
We previously already voted that 2.1.x would require 1.5.
Arnaud HERITIER wrote:
Bumping the Java requirement doesn't feel like a maintenance release IMHO.
Therefore, shouldn't we bump the Maven version to 2.2 as well and rename the
branch or create a new one?
+1 It's a too big change for
.
2009/4/14 Arnaud HERITIER aherit...@gmail.com:
Or you have to use SVN 1.5.0 or 1.6.0 bianires. No 1.5.x.
Arnaud
On Tue, Apr 14, 2009 at 11:33 PM, Brian Fox bri...@infinity.nu
wrote:
Raphaël Piéroni wrote:
Hi
Time to release the updated parent poms:
https://repository.apache.org/content/repositories/apache-staging-011/org/apache/apache/6/apache-6.pom
https://repository.apache.org/content/repositories/maven-staging-012/org/apache/maven/maven-parent/12/maven-parent-12.pom
The changes were described
The original dependency plugin filtering syntax was intended for a
different purpose. It was meant that you might filter only on group id
and not a combination of all the fields.
Paul Gier wrote:
I like the syntax that you chose using includes and excludes
containing a comma separated list of
Each of those fields maps to a separate filter in the artifact filters.
The filters grew over time but they were meant to be used separately
most of the time. So you might say copy all com.sonatype or exclude
org.apache but rarely try to specify and individual artifact...that's
what the
.
2009/4/14 Arnaud HERITIER aherit...@gmail.com:
Or you have to use SVN 1.5.0 or 1.6.0 bianires. No 1.5.x.
Arnaud
On Tue, Apr 14, 2009 at 11:33 PM, Brian Fox bri...@infinity.nu
wrote:
Raphaël Piéroni wrote:
Hi folks,
I try to prepare the release of the next version of the
archetype
This was a test. Emails will be sent out when new artifacts are staged
and again when things are promoted. This is to improve visability into
what is being deployed into the repo but the repo team and each dev team.
Nexus Repository Manager wrote:
The following artifacts have been staged to
We currently have some expectations about what artifacts are created for
apache builds, such as javadocs and source jars, and specifically
artifact signatures. Currently each project must configure the current
release profile in their own top level pom. This raises the bar of entry
for new
Martijn Dashorst wrote:
I think this is a great idea. You could even put the new apache wide
repository and staging area in the release profile. Would make doing a
release a snap IMO.
That part is already in Apache-5 ;-)
Raphaël Piéroni wrote:
Hi folks,
I try to prepare the release of the next version of the archetype plugin,
but i fail.
The release plugin tell me it can't create the tag.
I run mvn release:prepare -DdryRun=true without any problem,
but when i remove the dryRun, i got this exception :
[INFO]
+1
Benjamin Bentmann wrote:
Hi,
We solved 3 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540styleName=Htmlversion=14831
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11540status=1
Staging repo:
.
Brian Fox wrote:
The assembly plugin can construct a repo and put it in a zip, but I
would be surprised if this case is covered. then you would have to
devise a way to unpack the zip to the users local repo.
--Brian (mobile)
On Mar 13, 2009, at 4:38 PM, Kaveh Goudarzi ka...@itkaa.com wrote
The assembly plugin can construct a repo and put it in a zip, but I
would be surprised if this case is covered. then you would have to
devise a way to unpack the zip to the users local repo.
--Brian (mobile)
On Mar 13, 2009, at 4:38 PM, Kaveh Goudarzi ka...@itkaa.com wrote:
Hi Brian,
Awesome, thanks Hervé
--Brian (mobile)
On Mar 6, 2009, at 6:12 PM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
Le vendredi 06 mars 2009, Hervé BOUTEMY a écrit :
I tried to deploy a new 2.3-SNAPSHOT, just with the actual trunk
code, but
got a 401 return code from
No, 2.1 should be 1.5 so the job is wrong.
--Brian (mobile)
On Feb 25, 2009, at 2:32 AM, Brett Porter br...@apache.org wrote:
Sorry, I keep forgetting we're still 1.4 minimum on here. It's just
a test library - I can fix when I get back in a couple of hours.
- Brett
On 25/02/2009, at
The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0-beta-1
The Enforcer plugin is used to fail a build if certain constraints are
not met. There are too many standard rules to describe here, but check
out the site for more details:
IMO it should continue, I merely copied the artifacts from one
location to another. Inspecting the signatures should validate the
artifacts.
--Brian (mobile)
On Feb 18, 2009, at 8:16 AM, Vincent Siveton
vincent.sive...@gmail.com wrote:
Hi Dennis/Brian,
Does the vote could continue
The Maven team is pleased to announce the release of the Maven 2.0.10
This is a stable bug fix release and you can see the full list of
issues fixed at
http://maven.apache.org/release-notes.html
Enjoy,
-The Maven team
-
To
I have it on my todo to integrate mercury into the dependency plugin.
Most of the shared component will be superceded by mercury. It's too
early to say if the Interface will change or not
--Brian (mobile)
On Feb 16, 2009, at 5:54 PM, pi song pi.so...@gmail.com wrote:
I have just noticed
You will need to change the distmgt to match the new parent poms or
wait for those to be staged(I'm waiting for svn to be back up to
finish all the plugin updates)
--Brian (mobile)
On Feb 16, 2009, at 5:58 PM, Arnaud HERITIER aherit...@gmail.com
wrote:
Without any other comments, I'll
Thanks for reminding me. We'll implement a custom plugin to validate
the sigs and send a notification. If the sigs don't match, we can stop
the promotion.
--Brian (mobile)
On Feb 8, 2009, at 12:32 PM, Wendy Smoak wsm...@gmail.com wrote:
On Thu, Feb 5, 2009 at 10:19 PM, Brett Porter
Any thing fixed in 2.0.10/11 will be in 2.1+
--Brian (mobile)
On Feb 8, 2009, at 12:42 PM, Paul Benedict pbened...@apache.org wrote:
While I prefer 2.1 to be released soon, I am more interested in bug
fixes from 2.0.10 and 2.0.11 than the new features.
What do you guys think about moving
Is it released yet? The reason it didn't make the previous releases is
that it wasn't ready. I think it should be in 2.1 but not 2.0 at this
point
--Brian (mobile)
On Feb 8, 2009, at 1:03 PM, Lukas Theussl ltheu...@apache.org wrote:
Picking up the doxia thread:
I have the feeling Doxia
The range should simply skip 3.0alpha1 and 2
--Brian (mobile)
On Jan 29, 2009, at 12:45 AM, Arnaud HERITIER aherit...@gmail.com
wrote:
What i understand in brett's email is that its patches are for 2.1
branch
but he would like to add ITs to check those fixes in 2.1. His
question seems
Good point, I didn't consider things in a repo. We'll have to take the
last one in that case.
--Brian (mobile)
On Jan 26, 2009, at 6:21 PM, Brett Porter br...@apache.org wrote:
On 26/01/2009, at 12:17 PM, Brian E. Fox wrote:
It should be a validation error if we find duplicated entries.
The Maven team is pleased to announce the release of the Maven
Clean Plugin, version 2.3
This plugin is used to delete artifacts to provide a clean build.
http://maven.apache.org/plugins/maven-clean-plugin/
You should specify the version in your project's plugin configuration:
plugin
The Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.1
This plugin is used to copy and unpack artifacts and dependencies. It
also provides visualization and optimization tools for your project
dependencies.
I'm -1 to making a new format, but ambivalent about changing it to
match openssl standards
--Brian (mobile)
On Jan 2, 2009, at 5:31 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Hi,
With regard to MINSTALL-47, I would like to discuss if we can/should
change the format used
Pretty sure that's when he's targeting the stage/vote.
--Brian (mobile)
On Dec 22, 2008, at 2:00 PM, Jochen Wiedmann jochen.wiedm...@gmail.com
wrote:
On Mon, Dec 22, 2008 at 3:54 AM, Jason van Zyl
jvan...@sonatype.com wrote:
I plan to release it January 5th.
Beg your pardon, but
It's not just about ignorig the ids. What about the distmgt info that
would be needed to deploy... Or filtering or processing of it? I think
it's just better to keep processing of the Nixon separate.
--Brian (mobile)
On Dec 18, 2008, at 10:15 AM, Ralph Goers ralph.go...@dslextreme.com
The solution outlined below is the recommended way to handle this.
Copy/unpack was meant to handle external artifacts.
--Brian (mobile)
On Dec 18, 2008, at 4:28 PM, Jamie Whitehouse basil.whiteho...@genesyslab.com
wrote:
I've run into a similar situation and I'll explain how I resolved
Only the rsync to central and then to the mirrors has changed.
--Brian (mobile)
On Dec 12, 2008, at 3:13 AM, Jason Dillon ja...@planet57.com wrote:
Oh, I thought it was the same sync'ing as with sites, every few
hours, or has that changed now too?
--jason
On Dec 12, 2008, at 3:05 PM,
There's nothing presumptive about the fact that it HAS been deprecated
in trunk for quite some time now. (since it was still called 2.1-snap)
The aggregator is full of problems and usually leads to recursive
builds when you bind it to the lifecycle. A complely new concept is
needed to
=10500Create=Create
And I've staged RC-3 here:
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC3/
Please try it out and see if we have any remaining regressions over 2.0.9.
Thanks,
Brian
--
Brian Fox
Apache Maven PMC
http
Arnaud, the idea is to limit the scope to new regressions once we
start an RC. Otherwise we would spin in circles forever.
--Brian (mobile)
On Oct 29, 2008, at 2:04 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
ok brett,
I'll try to create a testcase without seam.
Even if we try to
You can't unset something like that because it appears null and the
merge will overwrite it. You could change it to something else though
--Brian (mobile)
On Oct 29, 2008, at 1:49 AM, Nick Pellow [EMAIL PROTECTED] wrote:
Hi,
If a plugin is defined in the normal build section of a pom and
Oleg you are mixing the use of this method with the method being
inefficient. Executing head is not ineficient so there's no reason to
exclude it in the new wagon. Taking it away simply because someone
could be dumb doesn't sense, especially since we already have on valid
use case for it.
Not all artifacts can be discovered via metadata so it's not safe to
assume you can always check there.
Sent from my iPhone
On Sep 29, 2008, at 10:08 PM, Oleg Gusakov
[EMAIL PROTECTED] wrote:
I implemented this method to pass ITs, it's existence is off the
table.
Brian Fox wrote:
Oleg
Ok, I'll take another look and if it works correctly put it back for v10
Sent from my iPhone
On Sep 13, 2008, at 6:12 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Brian E. Fox wrote:
No, it's available in the quality-checks profile as well.
I saw that but it didn't work. It tried to find
I don't but I don't know how not including it might affect the site
specifically. The parent isn't a magical thing and it's been 6 months.
Why not release it, do the enforcer and release it again? Release it 3
or 4 more times for good measure.
Sent from my iPhone
On Sep 8, 2008, at 4:47
Sounds good to me
Sent from my iPhone
On Sep 3, 2008, at 5:35 PM, John Casey [EMAIL PROTECTED] wrote:
Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we have a concrete strategy for
implementation including a design doc, I don't feel
Shane has reworked maven project with an eye towards these use cases.
This stuff is in maven 3.0
Sent from my iPhone
On Aug 25, 2008, at 8:26 PM, Ralph Goers [EMAIL PROTECTED]
wrote:
I'm still confused. If I had thought that it could be done that way
I would have done it in the first
As I said before, this was done by infra with no notice to us. The new
policy of purging is theirs, not ours. See the infra archives if you
would like to read about it.
On Aug 5, 2008, at 10:45 PM, Patrick Moore [EMAIL PROTECTED]
wrote:
Of course this means that the maven team is
No, it's not required to redo it as freestyle just to add fae
On Jul 30, 2008, at 9:45 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
Just use a freestyle project and then you can do whatever you like.
On 30-Jul-08, at 6:36 AM, Arnaud HERITIER wrote:
Is it possible ?
I never saw this option in
Go for it
Sent from my iPhone
On Jul 30, 2008, at 9:13 AM, Benjamin Bentmann [EMAIL PROTECTED]
wrote:
Hi,
while having a look at the recent failure during build #181 of maven-
shared, I noticed that the modules after the failing one were not
build at all (Build failed before it gets to
Just add -fae to the goals line. Until I verify the use separate repo
works I prefer to use the maven switch directly
Sent from my iPhone
On Jul 30, 2008, at 9:36 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
Is it possible ?
I never saw this option in hudson.
Is it the option called
What if we just turn off the repeated build failure emails?
Sent from my iPhone
On Jul 28, 2008, at 6:42 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
Hi
I think that we need to change the setup in Hudson for Maven
Plugins. Currently there is a job [1] called Maven-Plugins which
has a
She takes a lot of vacation :-)
--Brian (mobile)
On Jul 11, 2008, at 5:18 PM, Vincent Siveton [EMAIL PROTECTED]
wrote:
Not again ;)
Vincent
2008/7/11, Julia Antonova [EMAIL PROTECTED]:
I will be out of the office starting 12.07.2008 and will not
return until
28.07.2008.
I will
You mean bootstrap first, then use that build to run release:prepare...?
--Brian
On Jul 7, 2008, at 6:13 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
Hi,
I'm working release planning, and I want to define how we actually
build Maven for a release.
For me it essentially boils down to:
Use
I agree that this is a big regression and most people will stay on
beta 5 untill it's fixed... Possibly making a release without it
pointless
--Brian (mobile)
On Jun 27, 2008, at 9:26 AM, Bouiaw [EMAIL PROTECTED] wrote:
Just a user advice :
I don't know if it is a blocker for you, but
If we don't include the new artifact code, the we need to fix several
issues related to reresolving artifacts multiple times.
On Jun 13, 2008, at 5:28 AM, Brett Porter [EMAIL PROTECTED] wrote:
I went through the unscheduled bunch of issues looking for
reported 2.1 regressions this
My guess is that one of your plugins isn't resolving the correct scope
of dependencies and having the enforcer masks this.
Sent from my iPhone
On Jun 4, 2008, at 11:33 AM, Arnaud HERITIER [EMAIL PROTECTED]
wrote:
Are you sure ?
I tested it all the day and it doesn't work for me without
Hi jim, it might be a typo below, buy you still need to specify the
goa in the poml, just not the phase.
--Brian
On May 12, 2008, at 5:14 PM, Jim Bethancourt
[EMAIL PROTECTED] wrote:
Hi all,
I'm trying to bind my mojo to the package phase using @phase
package, and
it's not working.
The Apache Maven team would like to announce the availability of Maven
2.0.8. We closed out 32 issues and no major issues upgrading are
expected.
There is one slight change to be aware of, the test-classes folder is
now before the classes in the classpath to allow test resources to
override
Reporter: Brian Fox
This happened apparently randomly during a scheduled build. On the next
scheduled build, it was successfull.
Build Error
[ http://jira.codehaus.org/browse/MWAR-7?page=comments#action_59702 ]
Brian Fox commented on MWAR-7:
--
This is causing us some trouble now too. We need to load some jars from jasper
and if we don't know for sure what the classpath is, we're hosed.
Referenced
[ http://jira.codehaus.org/browse/MNG-2045?page=comments#action_59740 ]
Brian Fox commented on MNG-2045:
I believe this is related to MWAR-7 and MOJO-286
Maven can't compile against sibling test-jar dependency in multiproject (Test
Attached
2.0.3 messes up plugin parameters from CLI
--
Key: MNG-2112
URL: http://jira.codehaus.org/browse/MNG-2112
Project: Maven 2
Type: Bug
Components: Plugin API
Versions: 2.0.3
Reporter: Brian Fox
Priority
[ http://jira.codehaus.org/browse/MNG-2112?page=all ]
Brian Fox closed MNG-2112:
--
Resolution: Incomplete
Forget it. Must be those beers Jason talked me into. Everything is fine.
2.0.3 messes up plugin parameters from CLI
[ http://jira.codehaus.org/browse/MNG-2068?page=comments#action_59434 ]
Brian Fox commented on MNG-2068:
This seems to be fixed in 2.0.3. Should update the fixed in version so it shows
up in the jira report. Would be nice to have an it test for this to keep
[ http://jira.codehaus.org/browse/MNG-2054?page=comments#action_59328 ]
Brian Fox commented on MNG-2054:
I verified in my sample and in my real project that this appears to be fixed in
2.0.3. The fixed version should be updated so that the JIRA report
: 2.0.2
Reporter: Brian Fox
Attachments: plugins-add-dependency.patch
Added info about dependency plugin to plugins list in the mojo section
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http
[ http://jira.codehaus.org/browse/MNG-1898?page=comments#action_59128 ]
Brian Fox commented on MNG-1898:
Thank you!
Plugin classpath broken from 2.0 to 2.0.1
-
Key: MNG-1898
URL: http
Project descriptor section anchors missing
--
Key: MNG-2090
URL: http://jira.codehaus.org/browse/MNG-2090
Project: Maven 2
Type: Bug
Components: Documentation: General
Reporter: Brian Fox
I noticed that the anchors
[ http://jira.codehaus.org/browse/MNG-2068?page=comments#action_58508 ]
Brian Fox commented on MNG-2068:
No, it still fails. You must build from sample-project2 to see this problem.
If you build from the root or from sample-jar it works fine. The trouble
-2068
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.2
Reporter: Brian Fox
Priority: Critical
Attachments: sample.zip
I have a project that inherits from 2 (or more) parents. If the grand parent
(parent of my parent) isn't
[ http://jira.codehaus.org/browse/MNG-2068?page=comments#action_58468 ]
Brian Fox commented on MNG-2068:
Note: Sample attached above is incorrect. I'm still verifying if I can
reproduce my real problem in a sample. I'll update the attachment or close
[ http://jira.codehaus.org/browse/MNG-2068?page=all ]
Brian Fox updated MNG-2068:
---
Attachment: good-sample.zip
Multiple inheritance fails to find grand parent in ../../pom.xml when the
groupIds differ (Test Case Attached
Components: Inheritence and Interpolation
Versions: 2.0.2
Environment: WinXp
Reporter: Brian Fox
Attachments: sample.zip
See the attached sample. If a plugin execution is set in a parent of a parent,
when the child is built from either aggregator, the plugin execution runs
[ http://jira.codehaus.org/browse/MNG-2054?page=comments#action_58178 ]
Brian Fox commented on MNG-2054:
Further investigation using help:effective-pom shows that the plugin
configuration actually gets included 2x in the pom. Shouldn't executions
Versions: 2.0.2
Environment: WinXP
Reporter: Brian Fox
Priority: Critical
Attachments: sample.zip
I have 2 projects under a parent like so:
--Parent
--- sample-jar
--- sample-jar-user
sample-jar builds and installs a test-jar along with the normal jar.
sample-jar
[ http://jira.codehaus.org/browse/MNG-2045?page=comments#action_57987 ]
Brian Fox commented on MNG-2045:
Yes, I realize this is an unusual case. The code is something we are working to
fix, but it was working until I moved it into a common parent
[ http://jira.codehaus.org/browse/MNG-1898?page=comments#action_57528 ]
Brian Fox commented on MNG-1898:
Any progress on this issue? I would like to move forward with my plugins but
can't because of this. We are stuck maintaining a bunch of lame ant scripts
Components: documentation - guides
Versions: 2.0.2
Reporter: Brian Fox
I am pretty sure it used to be here, but it's gone now. This is a major first
hurdle to plugin development.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one
Release Plugin
Type: Bug
Reporter: Brian Fox
Priority: Blocker
My child poms effectively get merged with the parents and checked in for the
next development iteration. This basically breaks all inheritance completely
and I end up doing more work undoing it than if I just did
501 - 600 of 663 matches
Mail list logo
