On 31/08/2007, at 7:27 AM, Wayne Fay wrote:
If this is the case, how will we file it in JIRA? Do we need a "needs
votes" version? Or just back to 2.0.x with a comment in there?
I suppose a "needs votes" version is as valid as any other approach.
Then assuming it gets "enough" votes and commen
Wayne Fay wrote:
input on this issue. Its easy enough to do with SurveyMonkey, assuming
we can find someone to write it using neutral language to avoid
unintended bias.
Spoilsport!
How are people supposed to b*tch and moan about the biased survey
results if you go and get somebody to write up
> If this is the case, how will we file it in JIRA? Do we need a "needs
> votes" version? Or just back to 2.0.x with a comment in there?
I suppose a "needs votes" version is as valid as any other approach.
Then assuming it gets "enough" votes and comments, we can worry about
implementing it.
> Ho
On 29 Aug 07, at 10:40 PM 29 Aug 07, Brett Porter wrote:
It's possible with Archiva too, but James has given what I feel is
a perfectly valid reason why that's a pain, and it ends up in the
same logical result (a repository that has everything, but appears
not to).
That's not the iss
On 30/08/2007, at 3:32 PM, Jason van Zyl wrote:
On 29 Aug 07, at 10:06 PM 29 Aug 07, Wayne Fay wrote:
Does anyone else think this is a terrible idea? If we allow this
then there is no going back.
Yah, I'd love to hear it if anyone can pick holes in it, as I don't
want to steer down any bad
On 29 Aug 07, at 10:06 PM 29 Aug 07, Wayne Fay wrote:
Does anyone else think this is a terrible idea? If we allow this
then there is no going back.
Yah, I'd love to hear it if anyone can pick holes in it, as I don't
want to steer down any bad tracks repository wise either.
I'm not a huge fa
> > Does anyone else think this is a terrible idea? If we allow this
> > then there is no going back.
>
> Yah, I'd love to hear it if anyone can pick holes in it, as I don't
> want to steer down any bad tracks repository wise either.
I'm not a huge fan simply because I like the simplicity of "ever
On 30/08/2007, at 2:56 AM, Jason van Zyl wrote:
On 29 Aug 07, at 8:20 AM 29 Aug 07, Brett Porter wrote:
On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
Like with any other artifact (including if versions are split
across multiple repositories), it searches them all in sequence if
they
On 29 Aug 07, at 8:20 AM 29 Aug 07, Brett Porter wrote:
On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
Like with any other artifact (including if versions are split
across multiple repositories), it searches them all in sequence if
they aren't found in one.
This seems like a good pr
On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
On 28 Aug 07, at 10:08 PM 28 Aug 07, Brett Porter wrote:
Where are we with this?
The thread went a bit off the rails for some other stuff, and the
only other suggestion I saw was:
On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
But the ca
On 28 Aug 07, at 10:08 PM 28 Aug 07, Brett Porter wrote:
Where are we with this?
The thread went a bit off the rails for some other stuff, and the
only other suggestion I saw was:
On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
But the case that Atlassian wants solved would be very simple
On 29/08/2007, at 6:14 PM, Nigel Magnay wrote:
Which is great - it just felt like there was some disagreement between
whether it's actually a problem to be fixed :- "let's fix the local
repository" vs "Yes, I'm just saying separate processes should be
using
separate local repositories." which
Which is great - it just felt like there was some disagreement between
whether it's actually a problem to be fixed :- "let's fix the local
repository" vs "Yes, I'm just saying separate processes should be using
separate local repositories." which I didn't understand as I couldn't see
how a locally
I already responded to this here: http://www.nabble.com/Re%3A-local-
repositories-%28was%3A-http%3A--jira.codehaus.org-browse-MNG-3151%29-
p12286344s177.html
Cheers,
Brett
On 29/08/2007, at 4:49 PM, Nigel Magnay wrote:
If you are knowingly doing this then I would say different settings
via
>
> If you are knowingly doing this then I would say different settings
> via a build plan to prevent corruption or the CI mechanism serializes
> the builds.
>
How can one do this and still make use of all 8 cores to build on a
desktop machine (or all 16 on our CI server)? m2 builds could run
real
Where are we with this?
The thread went a bit off the rails for some other stuff, and the
only other suggestion I saw was:
On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
But the case that Atlassian wants solved would be very simple with
something like Proximity even today. One simple acce
oo many to count in my head ;-)
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 22, 2007 5:06 PM
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
>
>&
On 23/08/2007, at 7:12 AM, Stephen Connolly wrote:
Or a better local repository model ;-)
+1. I already started to draft a proposal for the wiki on this, but
hadn't posted it yet.
One where there are two local repositories (committed and current
build) that get layered together.
Wha
Sent: Wednesday, August 22, 2007 4:33 PM
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
Brian E. Fox wrote:
>> One big issue I have is that the maven-dependency-plugin seems to
>>
> ignore
>
>> artifacts produced in the current build
Jason van Zyl wrote:
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
How on earth do you have concurrency problems with a local repository?
Simultaneous builds in a CI system on a multicore machine.
If you are knowingly doing this then I would say different settings
via a build
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
How on earth do you have concurrency problems with a local
repository?
Simultaneous builds in a CI system on a multicore machine.
If you are knowingly doing this then I would say different settings
via a build plan to prevent cor
Brian E. Fox wrote:
One big issue I have is that the maven-dependency-plugin seems to
ignore
artifacts produced in the current build execution and only pulls from
the local repository... so I have to run "mvn install" all the time...
Which goal? The unpack, copy yes, but unpack/c
>One big issue I have is that the maven-dependency-plugin seems to
ignore
>artifacts produced in the current build execution and only pulls from
>the local repository... so I have to run "mvn install" all the time...
Which goal? The unpack, copy yes, but unpack/copy-dependencies will work
with p
>How on earth do you have concurrency problems with a local repository?
Simultaneous builds in a CI system on a multicore machine.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 22 Aug 07, at 12:42 PM 22 Aug 07, Stephen Connolly wrote:
Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you
On 8/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote:
>
> >
> >>
> >> It does if you use a shared file system, many people actually use
> >> this. And simple Window file perms work here to protect it.
> >
> > How do you deal with concurren
Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
That's easy
Jason van Zyl wrote:
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
One team of
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
Gregory Kick wrote:
How do you deal with concurrent writes?
That's a nightmare problem with the local repository anyway.
How on earth do you have concurrency problems with a local repository?
One team of ours had to scrap swit
On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote:
It does if you use a shared file system, many people actually use
this. And simple Window file perms work here to protect it.
How do you deal with concurrent writes?
There's nothing you can do here with Wagon in general right now.
Gregory Kick wrote:
On 8/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
Ok, so I'm coming to the conversation slightly late in the game, but
all of this discussion reminds me of something that's been in the back
of my mind for so
On 8/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
>
> > Ok, so I'm coming to the conversation slightly late in the game, but
> > all of this discussion reminds me of something that's been in the back
> > of my mind for sometime. With a
On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
Ok, so I'm coming to the conversation slightly late in the game, but
all of this discussion reminds me of something that's been in the back
of my mind for sometime. With all of the effort put forth in the
various repository managers, fron
Ok, so I'm coming to the conversation slightly late in the game, but
all of this discussion reminds me of something that's been in the back
of my mind for sometime. With all of the effort put forth in the
various repository managers, front-ends, proxies, mirrors, etc. why
doesn't the whole reposit
Jason,
> So why can't it all be in one repository? You have people who buy
> your products with a non-source license and you give them access to
> binaries from a Maven repository instead of an installer? Or you have
> updaters that use a Maven repository so you only need the binaries
> for
On 21 Aug 07, at 5:43 PM 21 Aug 07, James William Dumay wrote:
Sorry if I'm missing something but why they can't just publish
everything to their private repo and just mirror things
they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more in
> Sorry if I'm missing something but why they can't just publish everything to
> their private repo and just mirror things
> they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more infrastructure that
needs to be written and maintained in the buil
On 21 Aug 07, at 5:01 PM 21 Aug 07, Brian E. Fox wrote:
I'm not fan of featuritis, but it sounded like a valid use case, and
since it gives the same net effect and doesn't affect any backwards
compatibility I thought it was worth going ahead with.
Same here. There is already a concept of atta
On 21 Aug 07, at 4:58 PM 21 Aug 07, Brett Porter wrote:
On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
(I'm resending this mail from another account because previous one
seems to be stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). T
>I'm not fan of featuritis, but it sounded like a valid use case, and
>since it gives the same net effect and doesn't affect any backwards
>compatibility I thought it was worth going ahead with.
Same here. There is already a concept of attached artifacts and there is
a parameter for an alterna
On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
(I'm resending this mail from another account because previous one
seems to be stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). They ship their
jars
and javadocs to users who want to wr
(I'm resending this mail from another account because previous one seems to be
stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). They ship their jars
and javadocs to users who want to write plugins etc, but the sources
stay internal (or to paying
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
The use case seems to be for non open source projects. They want to
distribute
their binaries and jars publicly, but keep the sources internal. Not
that I
agree with this practice, but I'm guessing that i
The use case seems to be for non open source projects. They want to distribute
their binaries and jars publicly, but keep the sources internal. Not that I
agree with this practice, but I'm guessing that is one reason for these requests.
Eric Redmond wrote:
On 8/21/07, Stefano Bagnara <[EMAIL
On 8/21/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> Jason van Zyl ha scritto:
> > I'm not sure this is something we want to encourage before the patches
> > are applied. Keeping the sources and javadoc JARs together seems like
> > a good thing to do. The sources and javadocs located in diffe
Jason van Zyl ha scritto:
>
> If you are using the IDE integration how is it going to know where to
> find the sources and javadocs for debugging. That's one simple case.
> By adding a tweak to make the deployment diverge from the standard you
> potentially ruin the integration with other tooling.
On 21 Aug 07, at 9:43 AM 21 Aug 07, Stefano Bagnara wrote:
Jason van Zyl ha scritto:
I'm not sure this is something we want to encourage before the
patches
are applied. Keeping the sources and javadoc JARs together seems like
a good thing to do. The sources and javadocs located in different
Jason van Zyl ha scritto:
> I'm not sure this is something we want to encourage before the patches
> are applied. Keeping the sources and javadoc JARs together seems like
> a good thing to do. The sources and javadocs located in different
> locations doesn't seem to make much sense to me and there'
I'm not sure this is something we want to encourage before the
patches are applied. Keeping the sources and javadoc JARs together
seems like a good thing to do. The sources and javadocs located in
different locations doesn't seem to make much sense to me and there's
no real explanation with
49 matches
Mail list logo
