Reading the original proposal again, I've an idea:
The structure of the local repository should become:
>
> ~/.m2/repository
> |-- cache
> |-- remote
> | |-- apache.snapshots
> | |-- central
> | |-- codehaus.snapshots
> | `-- ...
> `-- workspace
> |-- default
> |-- workspace1
> `-- ...
>
> The purposes of these directories are as follows:
>
> * cache: immutable artifacts downloaded from a remote repository. No
> metadata is stored in this directory tree.
>
> * remote: contains a directory for each remote repository (by repository
> identifier). This contains the metadata and mutable artifacts from that
> repository. Metadata files will return to the format {{maven-metadata.xml}}
> instead of the current {{maven-metadata- <id>.xml}} file format. Files in
> these repositories will typically be snapshots and metadata for releases,
> since actual releases are not mutable and can be stored in the {{cache}}
> directory
>
> * workspace: contains a directory for each local workspace, with the
> primary one being {{default}}. This contains the metadata and files for any
> artifact built by maven (both snapshots, and releases).
>
Perhaps a better structure would be
~/.m2/
|-- repository (takes the form of cache from above)
|-- metadata (takes the form of remote from above)
| |-- local
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- temp (workspace for downloads prior to final move into storage)
`-- workspace (if necessary)
The idea is that the release artifacts will be stored in repository in the
current format (but we don't store the metadata there)
That way if m3 downloads an artifact, m2 can still pick it up.
We keep the metadata that m3 looks at in a separate tree, and we store the
-SNAPSHOTs along with the metadata in that tree.
We can provide tooling to purge -SNAPSHOTs from repository and to purge
artifacts associated with a specific metadata tree
-Stephen
2009/10/30 Mark Struberg <strub...@yahoo.de>:
> Thanks Stephen!
>
> Wasn't aware that Brett had the same idea a long time ago.
> Found it now:
>
> http://markmail.org/thread/wqi43wiwbj43vwq6
>
> It would be a good amount of work, but since this seems to pop up
regulary, we may think about it for m3.
>
> LieGrue,
> strub
>
>
>
> ----- Ursprüngliche Mail ----
>> Von: Stephen Connolly <stephen.alan.conno...@gmail.com>
>> An: Maven Developers List <dev@maven.apache.org>
>> Gesendet: Freitag, den 30. Oktober 2009, 10:27:36 Uhr
>> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies
>>
>> This was a proposal about a year or two back.... IIRC there were other
>> more pressing issues and nothing much happened since.
>>
>> The proposal was part of the "make repository access thread-safe" for
>> people using maven on CI systems, or running builds in parallel from
>> the CLI
>>
>> -Stephen
>>
>> 2009/10/30 Mark Struberg :
>> > Hi!
>> >
>> > Just make a step back and look at the repository problematic from a bit
>> different perspective.
>> >
>> > I'm working for a few companies and even different projects in those
companies
>> use different sections in their poms.
>> > But in my local repo, all the artifacts from those repositories gets
merged to
>> a single big landfill.
>> >
>> > When I switch to a different project, with no repositories configured,
I may
>> pick up a wrong dependency this way. Or I may be able to compile and even
>> release, but my colleagues are not, because this very is missing in
>> the projects pom.
>> >
>> > What about remembering where an artifact came from in the local repo?
>> > E.g. something like
>> >
>> > ~/.m2/repository // this contains the locally installed artifacts and
stuff,
>> and also acts for backward compatibility. It is always 'active']
>> > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache...
>> > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise...
>> >
>>
~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby...
>> >
>> > If a is not activated for a specific project then the local
>> artifacts will not be picked up. from .m2/repositories. If a transitive
>> dependency defines a new those will be added at the end of the
>> chain. We should think about collision detection, but this should be
detectable
>> at least.
>> >
>> > There are most probably also things to consider for repository
managers.
>> >
>> > I'm not sure if it is worth the effort though.
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> >
>> >
>> > ----- Ursprüngliche Mail ----
>> >> Von: Brian Fox
>> >> An: Maven Developers List
>> >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr
>> >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of
dependencies
>> >>
>> >> It's amazing how google's thread compression of a discussion can cause
>> >> me to overlook a huge thread so near and dear to my heart.
>> >>
>> >> To start, Benjamin has hit the nail on the head of a discussion point
>> >> Jason and I have had going for quite some time. In fact, we even wrote
>> >> up a proposal for it months ago that got little feedback. I've also
>> >> blogged on this subject before.
>> >>
>> >> Written and suggested reading in this order:
>> >>
>>
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>> >>
>>
http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery
>> >>
>> >> I won't rehash all of what I've already written, and leave it to the
>> >> reader to follow the above urls for the majority of the points however
>> >> I think there is one key argument that is worth reiterating:
>> >>
>> >> The ability of a user to checkout an open source project with no prior
>> >> knowledge of it and simply be able to build it, run the tests and
>> >> patch it the first try is the most powerful way to demonstrate the
>> >> Maven to new users. Simply removing or ignoring repositories in the
>> >> poms will break this functionality that I feel pretty strongly about.
>> >>
>> >> All of the arguments so far in this thread mostly revolve around
>> >> issues in corporate / enterprise use, and for these issues repository
>> >> managers are the best solution. I don't think its in the best interest
>> >> of the community to break OSS use to support Enterprise use,
>> >> particularly when that problem is already covered.
>> >>
>> >> Specifically, I'm pretty strongly in favor of continuing to support
>> >> repositories declared in poms, however they should be scoped for only
>> >> the subtree of dependencies introduced by the pom declaring the repo.
>> >> Further, I recognize that having urls burned into immutable poms is
>> >> not the best way to accomplish this, and I think we need to find a
>> >> better one pretty quickly.
>> >>
>> >> --Brian
>> >>
>> >> On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly
>> >> wrote:
>> >> > 2009/10/28 Brett Porter
>> >> >
>> >> >>
>> >> >> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote:
>> >> >>
>> >> >> On Wed October 28 2009 10:53:10 am John Casey wrote:
>> >> >>>
>> >> >>>> I tend to agree, they should not really be used. It seems like
these
>> >> >>>> third-party repositories have a strong potential for causing
network
>> >> >>>> errors (in cases where the repo is down or on a private network),
and
>> >> >>>> they definitely push the user in the direction of trusting
anything that
>> >> >>>> comes from anywhere on the internet without thinking twice...not
a great
>> >> >>>> idea, and an understandably unpopular one with companies.
>> >> >>>>
>> >> >>>> I think the role of the declaration in the POM should be
>> >> >>>> shifted in Maven 3. I think this along the same lines that Brett
was
>> >> >>>> talking, but I'd really like to see them take on an advisory role
rather
>> >> >>>> than actively participate in resolution. In other words, if an
artifact
>> >> >>>> cannot be found, then display the list of third-party
repositories which
>> >> >>>> MIGHT contain the artifact, along with the POM that lists that
>> >> >>>> repository.
>> >> >>>>
>> >> >>>
>> >> >>> I'm OK with that EXCEPT for repositories defined in the current
>> >> >>> pom+parents.
>> >> >>> For transitive dependencies, yes, but not for building the current
>> >> >>> project.
>> >> >>>
>> >> >>>
>> >> >> +1
>> >> >>
>> >> >> This avoids fudging with settings.xml, which has other problems
that
>> others
>> >> >> have mentioned, and also because you start building a long list of
>> >> >> repositories then used on *every* project (unless Maven adds some
other
>> gid
>> >> >> restriction on repositories).
>> >> >
>> >> >
>> >> > +1... though this has the side-effect that if you checkout a project
who's
>> >> > parent is only in a repository specified in the parent... well hey,
it's
>> not
>> >> > our fault! ;-)
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> On 29/10/2009, at 4:22 AM, Dan Rollo wrote:
>> >> >>
>> >> >> To advocate the other side: I like the ability to define
repositories in
>> >> >>> the pom.xml because team members (oss or corporate) can simply
"get
>> latest"
>> >> >>> from the source bank and things work OOTB.
>> >> >>>
>> >> >>> I don't like the idea that the only way for things to work OOTB is
if all
>> >> >>> artifacts MUST come from 'central'. There are other open source
repo's in
>> >> >>> wide use. Same with private/corporate repos.
>> >> >>>
>> >> >>> Forcing an edit to settings.xml (usually located in the user home
dir) is
>> >> >>> also a maintenance issue for automated builds.
>> >> >>>
>> >> >>
>> >> >> Agreed - I think the proposal above gives a balance between the two
>> >> >> concerns.
>> >> >>
>> >> >> - Brett
>> >> >>
>> >> >>
>> >> >>
---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
