Brett Porter wrote:
A few quick ones...
On 11/11/2008, at 7:27 AM, Oleg Gusakov wrote:
** code quality range per repository is introduced
Nice. Does this mean staging vs release, or is it keeping alpha/beta
or QA/test separate from final release?
Anything. Mercury is a library, not an ap
On 21/11/2008, at 12:09 AM, Brian E. Fox wrote:
2. switch several plugins to use mercury for resolution
2.1 dependency plugin
?? .. open for suggestions
I commented in the JIRA, but I think this should only live on a
branch
until Mercury is final. It can be a good way to test Mercury,
>>
>> 2. switch several plugins to use mercury for resolution
>> 2.1 dependency plugin
>> ?? .. open for suggestions
>I commented in the JIRA, but I think this should only live on a branch
>until Mercury is final. It can be a good way to test Mercury, but
>shouldn't get into a release. We hav
A few quick ones...
On 11/11/2008, at 7:27 AM, Oleg Gusakov wrote:
** code quality range per repository is introduced
Nice. Does this mean staging vs release, or is it keeping alpha/beta
or QA/test separate from final release?
* POM interpretation for these repositories defaults to mave
The webdav server which is currently a plexus component is here:
https://svn.sonatype.org/spice/trunk/plexus-webdav
It should probably be renamed as it's a server not a client
implementation.
On 14-Nov-08, at 9:55 PM, Oleg Gusakov wrote:
I added it to http://jira.codehaus.org/browse/MERCUR
Le jeudi 13 novembre 2008, Oleg Gusakov a écrit :
> Man, you got me scared s..less today when suddenly all my commits
> started failing because of conflicts with SVN :)
:)
>
> As for the mercury-pom - I guess we can move it into the upmost reactor
> POM if it's easier to work with it that way. May
I added it to http://jira.codehaus.org/browse/MERCURY-25
Will definitely try it. Thanks Stephen!
Stephen Connolly wrote:
There's also
http://milton.ettrema.com/index.html
Which is using the ASLv2 license.
I have not used it myself, but it's looking tempting for some stuff I want
to do (unles
There's also
http://milton.ettrema.com/index.html
Which is using the ASLv2 license.
I have not used it myself, but it's looking tempting for some stuff I want
to do (unless Jason wants to show me where his one is ;-) )
-Stephen
2008/11/12 Jason van Zyl <[EMAIL PROTECTED]>
> I've got one, I'll
Man, you got me scared s..less today when suddenly all my commits
started failing because of conflicts with SVN :)
As for the mercury-pom - I guess we can move it into the upmost reactor
POM if it's easier to work with it that way. Maybe you can create a jira
for that?
Thanks a lot!
Oleg
He
Le mercredi 12 novembre 2008, Oleg Gusakov a écrit :
> > inheriting from parent won't add any dependencies to the code. And if
> > dependencyManagements values don't fit your need, no problem to override
> > them. I don't see what we loose with this parent, but we win a lot of
> > things. Or we'll
I've got one, I'll pull it out of storage and show Oleg where it is.
On 11-Nov-08, at 9:40 PM, Jesse McConnell wrote:
aw yes...the world needs a good open source dav server thats easy to
setup...I haven't ever found one :/
if anyone knows of one that is easy to deploy as a test case please
c
You might be able to knock up a quick one using Milton [1].
http://milton.ettrema.com/index.html
Archiva also supports level 2 webdav - so you might be able to bring it
up inside of cargo.
Cheers
James
On Tue, 2008-11-11 at 20:40 -0600, Jesse McConnell wrote:
> aw yes...the world needs a good o
aw yes...the world needs a good open source dav server thats easy to
setup...I haven't ever found one :/
if anyone knows of one that is easy to deploy as a test case please chime in
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
On Tue, Nov 11, 2008 at 8:37 PM, Oleg Gusakov
<[EMAIL PROTECTED]>wrot
Jesse McConnell wrote:
oleg, I used the codehaus dav to test against, it worked quite wellif
you have a codehaus account you have a dav drive you can work with for it
dav.codehaus.org/user/oleg I believe
Jesse,
I also tested against codehaus and mercury does work well.
But I want tes
oleg, I used the codehaus dav to test against, it worked quite wellif
you have a codehaus account you have a dav drive you can work with for it
dav.codehaus.org/user/oleg I believe
catch me on irc and I can help
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
On Tue, Nov 11, 2008 at 7:20 PM, Ol
Herve,
There is another piece you can help with if you don't mind.
I used unit tests to shape up the functionality, but they can sure use
an independent eye. Plus writing more tests will help you to better
understand the code and then modify it.
Can you look into mercury-repo-virtual and wri
Brian E. Fox wrote:
It can go to central, we just need to setup the sync.
Regarding the parent, Oleg if you don't want the maven parent then you should
use the apache parent and copy some defaults from the maven parent.
It's not that I don't want - it's just that I'd rather do this
sequ
Jesse McConnell wrote:
I brought up the integration testing dependency earlier as well...imo if the
artifact is not going into the central repo then the pom needs to link to a
repository that will bring it in...
I will remove those deps from mercury-wagon -
http://jira.codehaus.org/browse/M
Hervé BOUTEMY wrote:
Le mardi 11 novembre 2008, Oleg Gusakov a écrit :
Hervé BOUTEMY wrote:
sorry, it is mercury-wagon that has the problematic dependencies
My bad, will drop - http://jira.codehaus.org/browse/MERCURY-25. Thanks
for the tip!
inheriting from parent won't add any dep
esday, November 11, 2008 5:18 PM
To: Maven Developers List
Subject: Re: Mercury status and roadmap
I brought up the integration testing dependency earlier as well...imo if the
artifact is not going into the central repo then the pom needs to link to a
repository that will bring it in...
people ought
Le mardi 11 novembre 2008, Oleg Gusakov a écrit :
> Hervé BOUTEMY wrote:
> > Hi Oleg,
> >
> > I had a look at the code, and I have some questions:
> >
> > - I can't compile the actual trunk since there is an artifact missing in
> > plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 an
I brought up the integration testing dependency earlier as well...imo if the
artifact is not going into the central repo then the pom needs to link to a
repository that will bring it in...
people ought to be able to checkout any maven project and build it using
strictly a stock maven install, no r
2008/11/11 Oleg Gusakov <[EMAIL PROTECTED]>:
>
>
> Hervé BOUTEMY wrote:
>>
>> Hi Oleg,
>>
>> I had a look at the code, and I have some questions:
>>
>> - I can't compile the actual trunk since there is an artifact missing in
>> plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and
>>
Hervé BOUTEMY wrote:
Hi Oleg,
I had a look at the code, and I have some questions:
- I can't compile the actual trunk since there is an artifact missing in
plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and
org.sonatype.appbooter:plexus-forked-app-booter:jar:1.4
Will these
Hi Oleg,
I had a look at the code, and I have some questions:
- I can't compile the actual trunk since there is an artifact missing in
plexus-mercury: org.sonatype.nexus:nexus-webapp:zip:bundle:1.0.1 and
org.sonatype.appbooter:plexus-forked-app-booter:jar:1.4
Will these artifacts be copied in C
25 matches
Mail list logo
