[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aether-users] MetadataResult.metaData.file as a means to convey available versions
|
On 03/26/2012 04:43 PM, Benjamin Bentmann wrote:
Carlo de Wolf wrote:
I'm looking at creating an alternative RepositorySystem
Why or what is the use case you are trying to solve?
Fedora currently uses mvn-rpmbuild to build Maven based projects.
mvn-rpmbuild is a modified Maven which in essence ignores version
designations. It can only be run on a system which has a JPP repository
and adheres to a different directory layout (so Fedora and some RPM
based friends).
We want to change this, so Fedora has a true Maven repository which
allows multiple versions installed. But at the same time we also don't
want to ship each and every version of each and every component (/ The
World), so for almost all components only the latest and greatest is
installed.
This in term means that most poms won't be able to find the version they
request. mvn-rpmbuild solves this by ignoring the version part, fmvn
however rewrites the request to use LATEST and pushes it back into the
Maven infrastructure. This in turn allows fmvn to be run on other
platforms besides Fedora.
I'm stuck at resolving a problem with returning metadata requests.
How exactly do those problems manifest themselves?
Whenever a version range, RELEASE or LATEST is requested (either in the
pom or through fmvn rewriting the request),
RepositorySystem.resolveMetadata is called. Then other components
(DefaultVersionResolver, DefaultPluginVersionResolver etc) will try to
open the file returned and parse it to get the versions overview.
Since JPP uses a different format it can't return any File which adheres
to maven-metadata.xml requirements. Thus I have to return null, which
ultimately leads to:
[DEBUG] Could not find metadata
org.apache.maven.plugins:maven-install-plugin/maven-metadata.xml in ...
Personally I think it is bad to use a File as a means to convey data.
The contents is 'soft-typed' and it entails extra resources just for
some piece of data, which might as well be in memory. In that light JPP
is just an example, other repository systems which want to hook into
Aether (if there are any) would suffer the same problem.
Carlo
There is no such file in some cases, because the backing repository
system (JPP in my case) has a different format.
I have no clue what JPP is. In case this is relevant to your issue, I
would appreciate if you could outline some of its specifics that are
of importance here.
I also have no knowledge about Fedora. That's just to say I was not
joking when I asked you to post here "detailing your use case". Until
I understand what you try to achieve and what is currently blocking
you, I cannot give proper advice.
Benjamin
_______________________________________________
aether-users mailing list
aether-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aether-users
