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
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
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
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
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
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
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
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
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;
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
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
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
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 not sure why
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
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
| `-- ...
|--
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
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
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
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
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
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
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
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
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
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,
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
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:
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 have
28 matches
Mail list logo
