Here's another batch comment...sorry for the bursty communication
style! :-)
Local Repo Separation Notes:
1. Having a strict (automatic) one-workspace-per-build approach kills
any idea of having integration-test runs that themselves have
predictable, isolated environments, and puts us back
On 18/09/2007, at 10:22 PM, Kenney Westerhof wrote:
Hi,
2. Workspaces should be something you have to set consciously,
not automatically created. This allows an integration-testing run
(for example) to run in isolation by using a different workspace
id, and clean up after itself when fin
Fair enough. Sounds good to me. -cg.
On 18-Sep-07, at 8:47 AM, Kenney Westerhof wrote:
If a CI only builds 1 project (-N, no reactor), then a per-build
workspace isn't needed. But a per reactor-build local workspace
as a default, when there are multiple projects in the reactor, as a
default,
Hi,
Reply is below.
Brett Porter wrote:
Hi Kenney,
On 14/09/2007, at 9:15 PM, Kenney Westerhof wrote:
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and projec
Christian Gruber wrote:
Hmm. I'm liking how this is all shaping up, but I'm wondering about the
"in the top level pom" bit. Already some things we do assuming a
reactor build are confusing because each project is built separately,
and when you start getting into continuum which essentially
Hmm. I'm liking how this is all shaping up, but I'm wondering about
the "in the top level pom" bit. Already some things we do assuming a
reactor build are confusing because each project is built separately,
and when you start getting into continuum which essentially replaces
the reactor w
Hi,
2. Workspaces should be something you have to set consciously, not
automatically created. This allows an integration-testing run (for
example) to run in isolation by using a different workspace id, and
clean up after itself when finished.
Agreed.
I think they should always be created,
Hi Kenney,
On 14/09/2007, at 9:15 PM, Kenney Westerhof wrote:
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and project artifacts.
The separation isn't clear in
Thanks John!
comments inline...
On 15/09/2007, at 3:07 AM, John Casey wrote:
1. We should put a piece of repository metadata at the root that
gives the repository id, to help eliminate/reduce the proliferation
of new and creative repository ids.
+1
Understandably, much of this gets us of
Sort of related to local repositories, and a thought that came back to me
after reading about separating snapshots and releases - could we do
something about caching the results of transitive dependency resolution? As
fast as XML pull parsing is, it's repeated over and over again for release
depend
Hi,
I've read the whole thread (so far), and I'm just going to give a
summary response here, rather than replying to each relevant email...
I think this proposal is a fantastic starting point. We've been
wrestling with issues of non-reproducibility and mistakenly broken
builds for a long
Hello,
My apologies if this answer is not relevant or has already been given:
I did not read the full contributions, just reacting to Brett's post.
I recently discovered the existence of nix (http://nix.cs.uu.nl/)
which is a kind of build system (rather a package and configuration
manager) that re
Hi,
I sent a mail a few days ago but it didn't make it to the list.
One very important feature would be the separation of build artifacts
(maven plugins and their dependencies), and project artifacts.
The separation isn't clear in maven itself - repo's get mixed up,
wrong repo's consulted; build
It will most likely work in small development environments.
What jason is saying is that it is not so likely to in corporate
environments with more than one subnet.
Andy
On 1 Sep 2007, at 17:59, Nigel Magnay wrote:
I guess ymmv, but I've never had zeroconf not work in development
environmen
On 2 Sep 07, at 6:35 PM 2 Sep 07, Brett Porter wrote:
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-c
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-cache
|-- snapshot-cache
`-- workspace
|-- default
>I know its another directory, but the following might be more
>straightforward:
>.
>|-- metadata
>| |-- apache.snapshots
>| |-- central
>| |-- codehaus.snapshots
>| `-- ...
>|-- release-cache
>|-- snapshot-cache
>`-- workspace
> |-- default
> |-- workspace1
> `-- ...
I'm no
On 02/09/2007, at 2:44 PM, Jason van Zyl wrote:
On 1 Sep 07, at 7:04 PM 1 Sep 07, Brett Porter wrote:
On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
For this proposal I think it boils down to the ephemeral versus
non. I think there is an easier way to do what is proposed.
Are you ta
On 1 Sep 07, at 7:04 PM 1 Sep 07, Brett Porter wrote:
On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
For this proposal I think it boils down to the ephemeral versus
non. I think there is an easier way to do what is proposed.
Are you talking about my proposal, or the settings zeroconf s
On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
For this proposal I think it boils down to the ephemeral versus
non. I think there is an easier way to do what is proposed.
Are you talking about my proposal, or the settings zeroconf stuff?
If it's for my proposal... let's hear the easier w
On 01/09/2007, at 6:22 PM, Stephen Connolly wrote:
Would a better option be to have the repositories store a
identifying GUID in their root URL. That way mirrors would pick up
the same GUID and be identified as the same repository.
Stephen - did you want to drop this into the user proposa
On 01/09/2007, at 3:06 AM, Arnaud HERITIER wrote:
Which new features can we imagine for corporate proxies like archiva,
proximity ? In that case developers often see only one remote
repository which is defined as proxy. How will we know the data come
from ?
I don't think anything is necessary i
I guess ymmv, but I've never had zeroconf not work in development
environments (we use the log4j zeroconf extensions all the time). Some
services deliberately set hopcounts low if they're providing something
particularly localized.
Anyway - I wouldn't suggest it as the only mechanism (and it's som
On 1 Sep 07, at 5:43 AM 1 Sep 07, Nigel Magnay wrote:
A couple of really neat features, regardless of whether guids or
some other
identifying mechanism is used, would be
1) ability to use zeroconf (/bonjour) style networking to
automatically
configure your mirror settings
In practice fro
A couple of really neat features, regardless of whether guids or some other
identifying mechanism is used, would be
1) ability to use zeroconf (/bonjour) style networking to automatically
configure your mirror settings
2) for repositories themselves to contain a bit more metadata about the
reposito
Jerome Lacoste wrote:
On 8/31/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Yeah, I meant to note that - I was thinking that this should be
accompanied by a proposal to take care of the id ambiguity problems
which we've discussed a couple of times before.
I think URLs are still problematic (si
On 8/31/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> Yeah, I meant to note that - I was thinking that this should be
> accompanied by a proposal to take care of the id ambiguity problems
> which we've discussed a couple of times before.
>
> I think URLs are still problematic (since you can often h
Which new features can we imagine for corporate proxies like archiva,
proximity ? In that case developers often see only one remote
repository which is defined as proxy. How will we know the data come
from ?
Arnaud
On 31/08/2007, Brett Porter <[EMAIL PROTECTED]> wrote:
> See: http://docs.codehaus
Yeah, I meant to note that - I was thinking that this should be
accompanied by a proposal to take care of the id ambiguity problems
which we've discussed a couple of times before.
I think URLs are still problematic (since you can often have
different ones for the same location), though are
looks great.
One comment. "Remote" folder is grouped by repo indentifiers.
Unfortunately these often differ among projects. Results in many
duplicate files and folder structures. Can we go by URL? or have some
means of automatically defining aliases for the same remote repo URL?
Milos
On 8/31/07
See: http://docs.codehaus.org/display/MAVEN/Local+repository+separation
Text included below for inline comments (which I'll feed back into
the document as needed).
Context
The current local repository is a single file structure, stored
typically in an individual user's home directory.
Th
31 matches
Mail list logo