Hi there,
I've had an initial stab at implementing ConflictResolvers and
attached a patch to MNG-612. If people wouldn't mind taking a peek,
I'd appreciate some feedback on the following:
1) ConflictResolver API - is the negative/positive/zero return type
sufficient, or would a boolean return
On 25/04/07, Brett Porter [EMAIL PROTECTED] wrote:
Cool, I'll take a look - since there seems to be a lot of talk about
maven-artifact right now, maybe this could be added to a list of
things to discuss while folks are f2f for the upcoming conferences.
I'll send a separate mail.
Thanks Brett.
Hi Jason,
Thanks for the reply. I was following the MNG-1577 debate and agree
that this is certainly a step in the right direction. The dependency
management solution is suitable for smaller projects with a manageable
set of transitive dependencies, although it starts to grow unwieldy
with
On 30/04/07, dhoffer [EMAIL PROTECTED] wrote:
Plugins seem to resolve version ranges in an inconsistent manor. If I have a
dependency version specified as [1.0,) how should this be resolved with
respect to SNAPSHOTS (in the opinion of the maven2 developers)?
Test case: Assume you have
On 02/05/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 2 May 07, at 2:26 PM 2 May 07, Brian E. Fox wrote:
Is there any tool or piece of tool in existence that can clean
snapshots
from a repo?
Tom's repositorytools in the mojo sandbox.
Which goal specifically? I can only see:
On 16/01/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 15/01/07, Gabriele Contini [EMAIL PROTECTED] wrote:
Some time ago i opened a jira issue about this missing feature:
http://jira.codehaus.org/browse/MRELEASE-177
Since this is a key feature for our company (we heavily use version
ranges
Hi there,
I'm working on tests for MRELEASE-177 which has led me to investigate
how ranges are resolved. An example problem was [1.0,2.0] resolving
to 2.0 irrespective of the repository metadata.
This appears to be due to VersionRange.getSelectedVersion and
isSelectedVersionKnown which selects
On 17/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Sounds like a bug to me...
Have a look at http://jira.codehaus.org/browse/MNG-2988 and see if
that makes sense.
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
On 30/04/07, Brett Porter [EMAIL PROTECTED] wrote:
As Mark further explained, I think his proposal is entirely different
and could be adapted to whatever strategy you apply in general here.
Was there any consensus on whether to apply MNG-612 to 2.0.x after all
the conferences?
Mark
On 18/05/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I'll be home on Monday and then I'll upload the spec I've written for
version resolution. Your code can be used but let's have folks look
at the spec first.
Cool, I'll look forward to having a read.
Cheers,
Mark
Hi there,
I'm wondering what the best approach is to fix MNG-2994 [1]. The
problem appears to be that the RepositoryMetadata implementation for
an artifact directory itself returns false for isSnapshot. The code
states that this is done since version information is below this
metadata, which
On 01/02/07, Brett Porter [EMAIL PROTECTED] wrote:
Edwin - can we double check the requirement here. I recently removed
this to prevent the problem of it failing if you haven't installed
the project first.
I was planning to reintroduce @requiresDependencyResolution test on
release:prepare to
On 22/05/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I'd like to release the release manager and the release plugin.
These versions included some bug fixes, a new goal for the branch creation and
the latest Maven-SCM (1.0)
The Road Map:
On 21/05/07, Brett Porter [EMAIL PROTECTED] wrote:
It seems more that you'd need to change the code that is relying on
the isSnapshot result from the wrong directory?
The code is fair enough given the limitation of a boolean return type:
ArtifactRepositoryPolicy policy =
On 21/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Using the manual resolution would only work if an earlier step in the
release:prepare process had definitely built all the dependencies.
However, there is an alternative: you can combine the reactor
projects (which you should have), with the
+1
Mark
On 23/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Hi,
We need to figure out where we go next with Archetype. Raphaël has
been doing a good job adding features and patiently listening to my
feedback/nagging. It appears to me that it is very close to being as
good as what we had before
On 24/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Yep, there's a few examples of plugins that re-use the resolution
mechanism and though I've never used it maven-downloader is meant to
encapsulate that in an easy to use API as well.
Looks like an infinite loop in the first
On 25/05/07, Brett Porter [EMAIL PROTECTED] wrote:
On 25/05/2007, at 12:57 AM, Mark Hobson wrote:
Looks like an infinite loop in the first DefaultDownloader.download
method.
Not sure what you're saying - you've tried it and it doesn't work, or
you just looked at the code and saw a problem
On 25/05/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I think we have this planned for 2.1. I know it's been discussed before.
You may be confusing this with a similar issue planned for 2.1:
http://jira.codehaus.org/browse/MNG-2589
I think what Christian is proposing is something akin to Maven
On 25/05/07, Mark Hobson [EMAIL PROTECTED] wrote:
Sure, I was envisaging that it could be fixed in 2.0.7 after which the
release plugin could have 2.0.7 as a prerequisite.
I've had a look at the code required to simulate
@requiresDependencyResolution, but it will require 2.0.6 due
On 29/05/07, Brett Porter [EMAIL PROTECTED] wrote:
Heh. Nice catch! Can you get that into JIRA?
Done: http://jira.codehaus.org/browse/MNG-3015
Sure, I was envisaging that it could be fixed in 2.0.7 after which the
release plugin could have 2.0.7 as a prerequisite.
Still an unreleased
Hi there,
I've submitted a new shared component, maven-runtime, which can be
used to introspect a runtime Maven environment:
http://jira.codehaus.org/browse/MNG-3026
I remember a long while back there was some talk on this list about
reading pom.properties from a given ClassLoader. Hopefully
On 30/05/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 29/05/07, Brett Porter [EMAIL PROTECTED] wrote:
So the sequence might need to be:
- resolve the project dependencies, filtering out the reactor projects
- add the reactor projects to the list of resolved artifacts
- iterate through
Hi Jason,
On 31/05/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Couple comments:
1. Classloaders are dictated by how ClassWorlds works and simply
looking at URLClassloaders isn't going to give you the whole picture
and might be misleading as ClassWorlds supports imports and can
change the
Hi there,
Is the ArtifactFilter passed into the ArtifactCollector.collect
methods meant to be applied before calls to the ResolutionListeners?
Currently it appears to disregard the filter whilst recursing and then
apply it only when calculating
ArtifactResolutionResult.artifactResolutionNodes.
On 04/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
Hi there,
Is the ArtifactFilter passed into the ArtifactCollector.collect
methods meant to be applied before calls to the ResolutionListeners?
Currently it appears to disregard the filter whilst recursing and then
apply it only when calculating
Hi Brett,
On 06/06/07, Brett Porter [EMAIL PROTECTED] wrote:
My recollection would be that some artifacts are filtered out but
their transitive dependencies still needed to be taken into
consideration for version calculations, so this could be the reason
for this.
If an artifact is filtered
On 01/06/07, Brett Porter [EMAIL PROTECTED] wrote:
Hi Mark,
Sure, jump on in your morning (or grab me on google talk, yahoo,
skype :). I'll still be here. Emmanuel should be around then too, and
he's done the most work on the release plugin recently.
We can post back with what we figure out...
On 07/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: brett
Date: Thu Jun 7 02:29:21 2007
New Revision: 545125
URL: http://svn.apache.org/viewvc?view=revrev=545125
Log:
[MNG-3023] apply integration test for issue (not yet fixed)
[snip]
Modified:
Hi Jason,
On 07/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Patrick how are you making out with MNG-2289?
And Mark and Brett, how are you making out with MNG-2988?
Brett's applied and closed MNG-2988. MNG-3039 needs to be applied
before another 2.0.7 release is staged.
I'm going to try
On 07/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
As in the next few hours, and you're reasonably sure it's all good? I
do the ITs and about 20 projects and feedback from another 20 or so
projects so if you're happy with this stuff then I'll start up
another cycle.
As far as I can tell it's
On 07/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Not in the long run :-) The ROI for a MAC is 10 minutes if you
consider the mental health costs.
I don't disagree, just that the bank manager says no.. :(
Mark
-
To
On 07/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Thu Jun 7 09:54:58 2007
New Revision: 545241
URL: http://svn.apache.org/viewvc?view=revrev=545241
Log:
Replacing JDK 1.5 api call.
Modified:
On 18/01/07, Mark Hobson [EMAIL PROTECTED] wrote:
Hi there,
On my travels I noticed DefaultArtifact [1] equals and hashCode
ignores scope - is that intentional? Could prove to be a problem when
check to see if an artifact has moved scope.
Just encountered this again whilst debugging - anyone
On 08/06/07, John Casey [EMAIL PROTECTED] wrote:
IMO, it's a representation of an artifact in the repository (or
elsewhere)...scope is just a tag designating its use within the
current build. Therefore, scope has nothing to do with whether two
artifacts somewhere on the system are equal.
So,
On 11/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Hi,
Just an update on 2.0.7. A couple things are preventing the staging.
I still can't get 2.0.7 to work with the XWiki build which is one of
the tests I use. I can't tell if it's something wrong internally or
with Surefire. During the tests I
On 11/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Do you have commit privs yet? If so then we can tag the 2.0.x branch
so you can actually try releasing and then we can rollback the POMs
to try again.
Not yet - Brett sent on an account request after receiving my CLA, but
I haven't heard
Hi,
I need an ArtifactFilter that supports wildcards and have patched
IncludesArtifactFilter accordingly, but then saw MNG-2621. I
implemented wildcards slightly stricter than allowing arbitrary
regular expressions - from the Javadoc:
The artifact pattern syntax is of the form:
Hi Brett,
On 06/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 06/06/07, Brett Porter [EMAIL PROTECTED] wrote:
My recollection would be that some artifacts are filtered out but
their transitive dependencies still needed to be taken into
consideration for version calculations, so this could
Hi there,
I've been working on dependency tree diagnostic tools and as a
consequence have made substantial changes to maven-dependency-tree. A
brief synopsis of changes are:
- support for node states: included, omitted for conflict, etc.
- node filter API and various implementations for
On 15/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: brianf
Date: Thu Jun 14 18:50:14 2007
New Revision: 547483
URL: http://svn.apache.org/viewvc?view=revrev=547483
Log:
MDEP-59: updated dependencies to get the new unarchiver for rar. Had to move
around the tests to avoid new heap
On 13/06/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Tue Jun 12 20:26:16 2007
New Revision: 546719
URL: http://svn.apache.org/viewvc?view=revrev=546719
Log:
o using the new groupId for the IT artifacts
Modified:
On 15/06/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
I think it's safest to assume no regexps at all, so your solution looks fine.
Jason, you said in MNG-2621 it could wreak havoc - how so? I think it's safer
to not
allow * for partial matches too, but we have no choice in the version
tag,
On 15/06/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Mark,
Can you subscribe to the commit list with your apache address? so I won't have
to moderate mails.
Thanks.
Ah sure, sorry, didn't realise that was happening. I'm not sure it's
working though since I sent a test email to [EMAIL
On 15/06/07, Andrew Williams [EMAIL PROTECTED] wrote:
Am I the only one getting a test failure on IT0002 with the 2.0.7
bundle?
junit.framework.AssertionFailedError: Expected file was not found: /
Users/aje/.m2/repository/org/apache/maven/its/maven-core-it-support/
On 15/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 15/06/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Mark,
Can you subscribe to the commit list with your apache address? so I won't
have to moderate mails.
Thanks.
Ah sure, sorry, didn't realise that was happening. I'm not sure it's
On 15/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
Yes, we should add it temporarily. I normally wouldn't use a snapshot but the
new archiver has a feature needed by mdep and they asked me to test it before
they do a release. It should be very short term.
Okay, cool.
Mark
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
If you install the artifacts you'll be fine. The invoker plugin broke
which is why they are not installed. You can't simply run the ITs,
you must install the plugins and artifacts that are used as part of
the ITs.
As I go through and find them
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I think you have two different things here. The first visualizing the
tree removing certain aspects and this implies the resolution is
complete and you're looking at a reduction. The second is actually
changing how the resolution happened in
Hi Jason,
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
That one small typo will render a system useless. What's the usecase
for not having to select individual artifacts to filter?
The filters are looking like something that will be used to exclude
dependencies and things of that nature
On 13/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
Hi there,
I've been working on dependency tree diagnostic tools and as a
consequence have made substantial changes to maven-dependency-tree. A
brief synopsis of changes are:
- support for node states: included, omitted for conflict, etc
On 15/06/07, Arnaud HERITIER [EMAIL PROTECTED] wrote:
Go for it. If you change some public APIs, try if possible to deprecate them
(in the case of some users used them)
Sure, but there has been some major refactoring so it may not be possible.
Mark
Hi Kenney,
On 16/06/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
Hi,
Just a quick question as to what this is for?
maven-dependency-tree is the shared component for computing dependency
trees from Maven's artifact resolution. The original code came from
project-info-reports:dependencies,
Hi Brian,
On 15/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
Mark,
There are already a bunch of filters defined within dependency for a lot
of this. None of them work for you or is it that you need to access them
from the shared component?
I did see them, although they weren't really what I
Hi John,
On 16/06/07, John Casey [EMAIL PROTECTED] wrote:
Just another pointer to add. I've put together some wildcard
filtering support for the assembly plugin, and factored it into a
separate library so I could share it with the maven-repository-
builder project. These wildcard-enabled
Hi there,
I'm working on adding omitted nodes support to dependency-tree and
have come across a limitation within DefaultArtifactCollector. The
problem is when one node is omitted for conflicting with a nearer node
and they have identical versions, i.e. they are duplicate nodes.
You can see in
Hi Joakim,
On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote:
Note, Archiva couldn't use the DependencyTree component, as it made
assumptions about repository access, availability, search order, and
layout that simply were not true. (actually, this is a problem mostly in
maven/components, but
Hi Brian,
On 18/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
I'm pretty sure I just wrapped the core artifactsFilter impl so that I
could deal with the collection. In any case that I can, I try to use the
core functionality but sometimes I wrap it to do any additional work
needed. This was done
On 18/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
As long as you run all the ITs and make sure they work before
committing. Running the unit tests is not enough unfortunately.
Sure, will do thanks.
And I'm still trying to get all the getting prepared for 2.1 before
I start fleshing out any
I've added the new filters to maven-common-artifact-filters as per
John's suggestion in MNG-2621. Let me know if there's any probs.
Mark
On 18/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
Hi John,
On 16/06/07, John Casey [EMAIL PROTECTED] wrote:
Just another pointer to add. I've put together
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 15/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
If you install the artifacts you'll be fine. The invoker plugin broke
which is why they are not installed. You can't simply run the ITs,
you must install the plugins and artifacts that are
On 19/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
You have to run the outter build first and what we want ultimately is
use a test remote repository before the ITs run. We have a problem
with them being coupled to the real central. The ITs should
ultimately be completely self contained. So
On 19/06/07, John Casey [EMAIL PROTECTED] wrote:
Sorry, I just realized that in my recent email shuffling, I lost one of the
mailing lists. Which one does JIRA send notifications on?
[EMAIL PROTECTED]
Is there a list of the maven MLs somewhere?
Yep, http://maven.apache.org/mail-lists.html
On 19/06/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
On 6/19/07, Mark Hobson [EMAIL PROTECTED] wrote:
Ah thanks, I wasn't aware of that - I had assumed archiva used
dependency-tree, although I haven't got around to looking at archiva
yet. That certainly looks like the kind of code I
On 19/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
If you do mvn install in the parent IT directory all the plugins
and artifacts required will be installed and the ITs will pass.
I'm sure we're crossing wires here:
[EMAIL PROTECTED] core-integration-testing]$ mvn install
...
[EMAIL
Hi Joakim,
On 19/06/07, Joakim Erdfelt [EMAIL PROTECTED] wrote:
I want to see maven 2.1 fixed in regards to project model resolution.
The current mess in maven/components is completely unusable within
archiva. If that occurs, then the rest of the dependency graph
resolution bits will fall into
Hi there,
I've having problems with DefaultArtifactCollector events when scopes
are being updated. The scenario in question is as follows:
p - a
a - c:test, b
b - c:compile
This resolves as follows:
1) c:test's scope is broadened to compile
2) p - a - c:test is disabled in
On 20/06/07, Brett Porter [EMAIL PROTECTED] wrote:
Can you change the logger to detect this and not re-report? This will
make -X output obscenely long (as if it wasn't already :)
Good catch - committed in both 2.0.x and trunk.
Cheers,
Mark
On 18/05/07, Brett Porter [EMAIL PROTECTED] wrote:
As it turned out, we didn't talk about the artifact resolution
mechanism in great detail. Jason told us he is working on a paper to
describe how it might be re-implemented in 2.1.
Jason, any chance you could push what you have into SVN so we
On 21/06/07, Brett Porter [EMAIL PROTECTED] wrote:
IT doesn't quite sound right - I would have expected it still select
nearest and apply the alternate scope from my recollection. But IIRC
behaviour was changed ~2.0.4 in relation to scopes, for some
particular reason and perhaps this is it:
Hi there,
Many of the plexus test cases fail in a fresh checkout of
maven-dependency-plugin with a linking error:
java.lang.NoSuchMethodError: org.codehaus.plexus.PlexusContainer.initialize()V
I assume this is to do with plexus-archiver being on
1.0-alpha-9-SNAPSHOT and surefire adding
On 21/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
That's odd, I am able to build mdep with no problems.
I'm building using the current 2.0.x branch, if that makes any difference?
Mark
-
To unsubscribe, e-mail: [EMAIL
On 22/06/07, Brett Porter [EMAIL PROTECTED] wrote:
Maybe I misunderstood, but I don't think the intention of this patch
is to allow other people to plug in their own, but simply allowing
them to use alternatives we've provided. The pluggable part certainly
needs to come later.
Yep, and in
On 22/06/07, Brett Porter [EMAIL PROTECTED] wrote:
It's never been an alternative, but it was implemented as newest
wins in an early alpha.
Curse the person who switched to nearest! ;)
How would anyone select a different strategy? This would require a
change to the POM to even turn on any
On 21/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I don't think this makes sense to add to 2.0.x as we have to 1)
provide a way to load these strategies which is taken care of in 2.1,
The method I've been using to switch conflict resolvers in 2.0.x is by
supplying an auxiliary components.xml
On 22/06/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
Well, just looked at the code and it's a mess. Here are the problems:
* The isSnapshot method does a regexp on the version for the timestamp, and if
it matches,
replaces the baseversion with -SNAPSHOT. If it doesn't match, checks for
On 22/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 22 Jun 07, at 2:56 AM 22 Jun 07, Mark Hobson wrote:
MNG-1577 is a small step in the right direction, but nearest conflict
resolution is the root cause of most of our dependency woes which sap
large amounts of developer time. As I
On 22/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 22 Jun 07, at 3:15 AM 22 Jun 07, Mark Hobson wrote:
As mentioned above, this requires a change in the Maven installation
rather than the POM. Obviously far from ideal, but I'm happy to live
with this for the huge gain in productivity
On 21/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
That's odd, I am able to build mdep with no problems.
I'm building using the current 2.0.x branch, if that makes any difference?
Same problem with 2.0.5, 2.0.6 and 2.0.7..
Mark
On 22/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
That's odd, I am able to build mdep with no problems.
I'm building using the current 2.0.x branch, if that makes any difference?
Same
On 22/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 22/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 21/06/07, Brian E. Fox [EMAIL PROTECTED] wrote:
That's odd, I am able to build mdep with no problems.
I'm building using the current
On 24/06/07, Brett Porter [EMAIL PROTECTED] wrote:
Sorry :(
At the time, the repository data (mostly converted from m1) wasn't
suited to it and you got things you didn't expect. I always expected
you'd be able to turn it on and manage the dependencies properly but
the implementation of that
On 24/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
For the branch if it was 100% non-invasive i.e did not interfere at
all with _anything_ setup currently, did not change the default
conflict resolver and was undetectable by the common user, and you
took responsibility and ownership of any
On 25/06/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
Mark Hobson wrote:
Now, there are three solutions: 1) Update all other components that
also depend on this dependency so there are no version conflicts; 2)
Add the bug fix version to the main project's depMan; 3) Rely on the
conflict
On 25/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Yah, sounds fine to be. It seems non-invasive and the onus is on you
so if something goes wrong I know who to look for :-)
Okay, I'll work on trying to get it working via extensions a little
more then submit another patch for any final
On 25/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
Mark,
Can you help me make proposals like this more visible not only to
developers who might be interested, but to folks looking in at the
project for the first time.
I am trying to collect all pertinent information to the project here:
On 26/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
We can quickly try this little process if you put your proposal on
the main proposals page, then we'll put it in the pending section and
we can ask people to look at vote. Would probably be the easiest as
you have to field the feedback as a
Looks good in general. I found it a little confusing how the info was
split across the two pages (Home and All Proposals). How about
changing the All Proposals page to encapsulate all proposal
information in one table? It would look similar to the
work-in-progress table on Home, but it could
the contextualizable bit to the existing classes - not
sure if that's an issue or not.
Cheers,
Brett
On 26/06/2007, at 2:06 AM, Mark Hobson wrote:
On 24/06/07, Brett Porter [EMAIL PROTECTED] wrote:
Sorry :(
At the time, the repository data (mostly converted from m1) wasn't
suited
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote:
Looks good in general. I found it a little confusing how the info was
split across the two pages (Home and All Proposals). How about
changing the All Proposals page to encapsulate all
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I think I like having a listing of the work in progress on the main
page so that you don't have to click to another page to see the work
in progress.
That said I like them all on one page, but I would like to extract
the current ongoing work
On 27/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
The alternative of using role hints would be preferable, so thanks for
the pointers, I'll try implementing this now. What's the best place
in the POM to configure the role hint with changing the schema though?
Is there a reserved namespace
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
The gross thing the wagon manager does for the proxy, etc is to push
the settings in from the core to the wagon manager itself so there's
passing it through the api.
Otherwise, I guess you'll need to pass the conflict resolver property
through
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
The other sticking point was how to propagate
ConflictResolverNotFoundException. I'd rather not wrap it up in a
misleading checked exception, and I'm not sure how people feel about
adding
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I thought we agreed that this was not to surface in a POM? If you put
that in there now people will start using it. I thought you were
going to be able to do this strictly by changes to your installation?
The initial way I got this working
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
One nitpick is that I think we should stick to property names that
follow Java variable name conventions like mavenConflictResolvers,
and this also prevents any screw ups with any ELs or expression
resolvers that might potentially get confused
On 28/06/07, Mark Hobson [EMAIL PROTECTED] wrote:
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
One nitpick is that I think we should stick to property names that
follow Java variable name conventions like mavenConflictResolvers,
and this also prevents any screw ups with any ELs
On 28/06/07, Patrick Schneider [EMAIL PROTECTED] wrote:
Howdy,
Is there anything special that needs to happen for the dependencies
section to get written out when using generateReleasePoms and version
ranges? I'm getting everything *but* the dependencies section written
out. Simple hello
On 28/06/07, Brett Porter [EMAIL PROTECTED] wrote:
On 29/06/2007, at 2:35 AM, Mark Hobson wrote:
I'll write an IT tomorrow than demonstrates this behaviour, but it's
pretty easy to try out.
Neat!
Added it0125 to verify switching to newest-wins conflict resolution.
Mark
On 28/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
As long as you track this in your proposal and end result amounts to
what this is going to look like in a v4 POM in 2.1 where hopefully
we'll have something nicer like:
conflictResolvers
conflictResolverx/conflictResolver
1 - 100 of 631 matches
Mail list logo
