Hi
We have similar goals in two plugins:
-
https://www.mojohaus.org/build-helper-maven-plugin/remove-project-artifact-mojo.html
-
https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html
By the way, using such goals is not recommended today with Maven 3 and so
Hello Everyone,
What do you think of adding an option like manualncludeByGroupid to dependency
plugin (goal -purge-local-repository) to delete all the dependencies based on
groupId, so that plugin can delete dependencies that matches with the provided
list of groupId’s in
for all the Maven smartness, and we try to avoid
> non-Maven API based features.
>
> However, there is a simple case we're missing to implement properly:
> listing artifacts in local repository. We could indeed just list the
> filesystem and that would work well enough, but I'
listing artifacts in local repository. We could indeed just list the
filesystem and that would work well enough, but I'm afraid it's duplicating
some logic that might already exist in Maven.
So the question is: is there already some API to list content of the local
repository as Maven
Jan 2017 at 17:02, Stephen Connolly <
> >
> > > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> >
> > >> I don't like this... but it fixes the test... unless anyone has a
> better
> >
> > >> proposal I will merge this t
Wed 11 Jan 2017 at 17:02, Stephen Connolly <
>
> > stephen.alan.conno...@gmail.com> wrote:
>
> >
>
> >> I don't like this... but it fixes the test... unless anyone has a better
>
> >> proposal I will merge this to master
>
> >>
>
&
7d19f88
[MNG-3599] Need to use --legacy-local-repository on newer maven versions
Project:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/repo
Commit:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/a27d19f8
Tree:
http://git-wip-us.apac
dated Branches:
>
>
> refs/heads/mng-3599 03c07e10b -> a27d19f88
>
>
>
>
>
>
>
>
> [MNG-3599] Need to use --legacy-local-repository on newer maven versions
>
>
>
>
>
>
>
>
> Project:
> http://git-wip-us.apache.org/repos/asf/mave
3599] Need to use --legacy-local-repository on newer maven versions
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven-integration-
> testing/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven-integration-
> testing/commit/a27d19f8
> Tree: http://git-wip-us.apache.
possible to install locally, although I am not sure we'll need
> separate "install" phase.
>
+1
Jeff
>
> --
> Regards,
> Igor
>
>
> On 2014-04-17, 7:13, ROBERT PATRICK wrote:
>
>> I don't understand the issue. I regularly use artifacts in m
t; build sample projects for customers that I never intend to do
> > anything else with once I send it to the customer).
>
> A remote repository is specified with an URL. Nobody prevents you
> from using a file URL i.e. having a real local repository on your
> disk.
Or using "
Am Thu, 17 Apr 2014 07:43:13 -0400
schrieb Igor Fedorenko :
> My problem with current behaviour is that the same location is used as
> both cache for remote artifacts and repository for locally installed
> artifacts.
Actually I agree, it would be good to have a "real" cache which is 1:1
existing
ot;install" phase.
--
Regards,
Igor
On 2014-04-17, 7:13, ROBERT PATRICK wrote:
I don't understand the issue. I regularly use artifacts in my build
that are only present in my local repository. Yes, Maven checks my
remote repository for these artifacts but it doesn't ignore th
ROBERT PATRICK wrote:
> I don't understand the issue. I regularly use artifacts in my build that
> are only present in my local repository. Yes, Maven checks my remote
> repository for these artifacts but it doesn't ignore them if they are not
> in the remote repo. It al
I don't understand the issue. I regularly use artifacts in my build that are
only present in my local repository. Yes, Maven checks my remote repository
for these artifacts but it doesn't ignore them if they are not in the remote
repo. It also works when building offline without ac
a cache,
>> but the tag names and the docs makes it hard to spread the word.
>>
>> In settings.xml : could be renamed to or
>> ?
>>
>> In the docs, e.g. https://maven.apache.org/pom.html there're many
>> references to a "local repository".
>
really a local repo, more a cache,
but the tag names and the docs makes it hard to spread the word.
In settings.xml : could be renamed to or
?
In the docs, e.g. https://maven.apache.org/pom.html there're many
references to a "local repository".
WDYT?
Cheers
-- Forward
it hard to spread the word.
In settings.xml : could be renamed to or
?
In the docs, e.g. https://maven.apache.org/pom.html there're many
references to a "local repository".
WDYT?
Cheers
-- Forwarded message --
From: Stephen Connolly
Date: 2014-04-15 10:12 GMT+
ime I looked at the code base I did not see a way to do a drop in JAR
> for this business logic. But I will look harder.
>
> Are you suggesting the change would be to call an optional support module
> instead to lookup what to do?
Yes, the code base since 3.x has supported injectin
> - -
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > This message is copyright PD Inc, subject to license 20080407P00.
> >
> >
> >
> >> -Ori
07P00.
>
>
>
>> -Original Message-
>> From: Jason van Zyl (JIRA) [mailto:j...@codehaus.org]
>> Sent: Sunday, January 19, 2014 14:36
>> To: jpye...@pdinc.us
>> Subject: [jira] (MNG-5167) relative local repository settings
>>
>>
>>
ct: [jira] (MNG-5167) relative local repository settings
>
>
> [
> https://jira.codehaus.org/browse/MNG-5167?page=com.atlassian.j
ira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Jason van Zyl closed MNG-5167.
> --
>
> Resolution:
Hello, maven dev,
A while a go, I introduced alternate local repo at
dependency:copy/unpack time. It is now not working for maven 3, any
help/advice on how to fix this issue is greatly appreciated
http://jira.codehaus.org/browse/MDEP-313
Thanks
-Dan
---
Use or look at the dependency plugin. The copy/unpack goals manually
resolve things to the repo.
On Wed, Apr 14, 2010 at 11:30 PM, Mirko Jahn wrote:
> Hey there,
>
> I am currently trying to manually install an artifact from a remote
> repository into the local repository to
Hey there,
I am currently trying to manually install an artifact from a remote
repository into the local repository to do some file operations on it.
I can resolve the artifact with:
resolver.resolve(dependency, remoteRepositories, repository);
But this doesn't install the artifact locall
Igor Fedorenko wrote:
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
I originally checked this in because it made a huge difference at my
organization. My goal was to reduce the time required to do a "no op"
build.
Our multi-module buil
Igor Fedorenko wrote:
Sorry, I did not mean to sound prescriptive. This is just another
idea you may choose to consider or ignore.
Yeah, I got that :-) My previous short answer was just intended to
express my lack of interest in a long discussion about this topic. The
special handling for PO
but with these optimizations, the jar plugin could decide not to
repackage as all the files it would add have the same size and
timestamp as inside the jar
without these opts such an optimization is of less use
Sent from my [rhymes with tryPod] ;-)
On 28 Dec 2009, at 14:06, Igor Fedorenko
Benjamin Bentmann wrote:
Igor Fedorenko wrote:
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
I did not benchmark this. This is about IO, so pick a module count, an
average artifact size and IO throughput.
From my experience, "feeling"
Igor Fedorenko wrote:
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
I did not benchmark this. This is about IO, so pick a module count, an
average artifact size and IO throughput.
Also, I think implementation should behave the same for
If we want to study the impact on performances, I think we have to create a
test case with a project creating wars and ears of several dozen of Mb.
I already saw some projects like that (an EAR of 100Mb with 2 wars of 50Mb).
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exop
Benjamin,
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
Also, I think implementation should behave the same for pom and other
artifacts. I would not want to have to troubleshoot "strange" build
failures should pom get out of sync with the res
Brian Fox wrote:
I'm in favor of pulling this back or changing it to check for exact
timestamp and size.
I consider both the workflow outlined by Tamás and the need for
optimization valid points so instead of pulling it out completely I
opted to improve the existing logic. In the next alpha
t;>>>>>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
>>>>> this
>>>>>>> case, IMHO.
>>>>>>>
>>>>>>> But even then, I dislike very much the
gt;>>>>>>> since I branch it to do some feature that I know will get back into
>>>>>> trunk.
>>>>>>>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
>>>>>> this
>>>>>
; trunk.
>>>>>>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
>>>>> this
>>>>>>> case, IMHO.
>>>>>>>
>>>>>>> But even then, I dislike very much the
>> ~t~
>>>> >>
>>>> >> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER
>>>> >> wrote:
>>>> >>
>>>> >> You have the same version in 2 branches in a project ?
>>>> >>> For me
>> wrote:
>>> >>
>>> >> You have the same version in 2 branches in a project ?
>>> >>> For me it is a bad practice
>>> >>> Each branch has it own version
is a bad practice
>> >>> Each branch has it own version to avoid those sort of conflict.
>> >>>
>> >>>
>> >>> Arnaud Héritier
>> >>> Software Factory Manager
>> >>> eXo pla
> Arnaud Héritier
> >>> Software Factory Manager
> >>> eXo platform - http://www.exoplatform.com
> >>> ---
> >>> http://www.aheritier.net
> >>>
> >>>
> >>>
rt of conflict.
>>>
>>>
>>> Arnaud Héritier
>>> Software Factory Manager
>>> eXo platform - http://www.exoplatform.com
>>> ---
>>> http://www.aheritier.net
>>>
>>>
>>> 2009/12/7 Tamás Cservenák
>>
> For me it is a bad practice
> > > > Each branch has it own version to avoid those sort of conflict.
> > > >
> > > >
> > > > Arnaud Héritier
> > > > Software Factory Manager
> > > > eXo platform - http://www.exoplatform.c
servenák
Hi there,
this is mainly about this issue:
http://jira.codehaus.org/browse/MNG-4368
It caused a lot of grief (and lost hours) to me, until I figured what
happens on me.
IMHO, no "optimization" like this should be done against local
r
http://www.exoplatform.com
> > > ---
> > > http://www.aheritier.net
> > >
> > >
> > > 2009/12/7 Tamás Cservenák
> > >
> > > > Hi there,
> > > >
> > > > this is mainly about this issue:
> > > > http://jira.codehaus.org/browse/MNG-4368
> > > >
> > > > It caused a lot of grief (and lost hours) to me, until I figured what
> > > > happens on me.
> > > >
> > > > IMHO, no "optimization" like this should be done against local
> > > repository.
> > > >
> > > > Please undo it.
> > > >
> > > >
> > > > Thanks,
> > > > ~t~
> > > >
> > >
> >
>
t; > eXo platform - http://www.exoplatform.com
> > ---
> > http://www.aheritier.net
> >
> >
> > 2009/12/7 Tamás Cservenák
> >
> > > Hi there,
> > >
> > > this is mainly about this issue:
> > > http://jira.codehaus.org/browse/MNG-4368
>
,
> >
> > this is mainly about this issue:
> > http://jira.codehaus.org/browse/MNG-4368
> >
> > It caused a lot of grief (and lost hours) to me, until I figured what
> > happens on me.
> >
> > IMHO, no "optimization" like this should be done against local
> repository.
> >
> > Please undo it.
> >
> >
> > Thanks,
> > ~t~
> >
>
Hi there,
>
> this is mainly about this issue:
> http://jira.codehaus.org/browse/MNG-4368
>
> It caused a lot of grief (and lost hours) to me, until I figured what
> happens on me.
>
> IMHO, no "optimization" like this should be done against local repository.
>
> Please undo it.
>
>
> Thanks,
> ~t~
>
Hi there,
this is mainly about this issue:
http://jira.codehaus.org/browse/MNG-4368
It caused a lot of grief (and lost hours) to me, until I figured what
happens on me.
IMHO, no "optimization" like this should be done against local repository.
Please undo it.
Thanks,
~t~
On Wed, Jun 24, 2009 at 10:07 AM, Jason Voegele wrote:
> Thanks for the response. I guess I'll try my hand at using a lock file or
> something similar in my wrapper scripts. I'm thinking that this algorithm
> might work:
You might look at Don Brown's work on parallel resolution of artifacts
[1]
Brian Fox wrote:
Almost certainly no. The 2.1 you saw mentioned most likely refers to
the old 2.1 that is now 3.0. FWIW, I don't believe this has been or
will be addressed in 3.0.0 which is focused on 2.x compatibility.
http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/
Thanks
at 5:55 AM, Jason Voegele wrote:
> I am wondering if it is now safe to have multiple Maven 2.1.0 processes
> running concurrently using the same local repository. I know that with
> older versions of Maven this was certainly not safe, but reading comments on
> some JIRA issues leads m
I am wondering if it is now safe to have multiple Maven 2.1.0 processes
running concurrently using the same local repository. I know that with
older versions of Maven this was certainly not safe, but reading
comments on some JIRA issues leads me to believe that this may have been
addressed
John,
> Subject: Re: How to get path to the local repository?
>
> If you're injecting this information into a plugin parameter,
> you can use the expression '${localRepository}' to get the
> ArtifactRepository instance, then call getBasePath() from that, IIRC
ry();
gives me null (probably because I don't have an explicit path in the
settings.xml file).
I also tried:
ArtifactRepository localRepo;
localRepo.getBasedir();
but this doesn't work.
How do I get the path to the local repository? I'm sure that Maven computes
it, because a ${sett
I tried:
Settings set = new Settings();
set.getLocalRepository();
gives me null (probably because I don't have an explicit path in the
settings.xml file).
I also tried:
ArtifactRepository localRepo;
localRepo.getBasedir();
but this doesn't work.
How do I get the path to the local
I don't think it works with 2.1 (which has the embedder used by M2E and Q4E).
-Original Message-
From: Mark Struberg [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 3:15 AM
To: Maven Developers List
Subject: Re: Relative path to local repository?
I tried the following, and
-plugin:2.5 brought up
> > http://jira.codehaus.org/browse/MECLIPSE-404
> > which is caused by (windows) users specifying drive-relative paths to their
> > local repos.
> >
> > Further progress on this issue would require some clarification:
> > Is Maven
ipse-plugin:2.5 brought up
> http://jira.codehaus.org/browse/MECLIPSE-404
> which is caused by (windows) users specifying drive-relative paths to their
> local repos.
>
> Further progress on this issue would require some clarification:
> Is Maven supposed to support relative paths to
relative paths to the local repository or is
the corresponding configuration in the settings.xml always expected to be an
absolute path? In the later case, I would create an issue to make Maven
actually validate the absoluteness of the path to save plugins from
unexpected relative-path effects
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,
build (plugin/extension) dependencies from the project dependencies. I
think this is most important for the metadata and snapshots - I don't
think we need duplicate copies of plexus container releases, etc
floating around in the local repository.
Definitely not. Though in fact only snapshot
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,
ndencies from the project
dependencies. I think this is most important for the metadata and
snapshots - I don't think we need duplicate copies of plexus
container releases, etc floating around in the local repository.
This will help to some extent by already separating some things out
(in pa
sharing a local repository and more about organizing the local
repository for more efficient usage. However, in cases where the
immutable cache/ dir can be shared between processes on the
localhost (maybe two builds by two users, maybe CI, who knows?)
there should be an ability to con
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
ilds for a long time now, not to mention all the trouble we've had
with interrupted artifact/metadata files etc. and I think this is
getting us back on track to address one of the cruftiest parts of
Maven - the local repository. It requires a high degree of knowledge
about the inner
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
. Perhaps
now this can be taken into consideration with this proposal.
[1] http://jira.codehaus.org/browse/MNG-724
Brett Porter wrote:
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 n
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
r in terms of their Maven
usage. The only affect is "finding something" if they go digging
around in the local repository - which you pointed out at the end so
I'll come back to it.
An option to use a separate local repository goes a long way and
with a cached remote using P
stuff?
I'm talking about your proposal being too complicated. An option to
use a separate local repository goes a long way and with a cached
remote using Proximity this is not loathsome. I don't think using a
shared local repository is a particularly bright idea. But creating
a
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
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&
se 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, Brett Porter <[EMAIL PROTECTED]> wrote:
See: http://docs.codehaus.org/display/M
s
On 8/31/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> 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
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
: dependency:purge-local-repository and includes?
And how do I configure the groupId to be used?
--jason
On Apr 4, 2007, at 8:12 PM, Brian E. Fox wrote:
> Use resolutionFuzziness=groupId
> http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-
> repo
> sito
PROTECTED] On Behalf Of Jason
Dillon
Sent: Wednesday, April 04, 2007 9:41 PM
To: Maven Developers List
Subject: dependency:purge-local-repository and includes?
Would it be possible to get the dependency:purge-local-repository to
specify a set of groupId, groupId:artifactId's that will be
clob
: dependency:purge-local-repository and includes?
Would it be possible to get the dependency:purge-local-repository to
specify a set of groupId, groupId:artifactId's that will be
clobbered, leaving all others alone?
I'd like to add something like this to my integration test profile to
Would it be possible to get the dependency:purge-local-repository to
specify a set of groupId, groupId:artifactId's that will be
clobbered, leaving all others alone?
I'd like to add something like this to my integration test profile to
nuke all of the org.codehaus.mojo.groovy
Sorry - Substitute maven-metadata.xml where I have
repository-metadata.xml.
Cheers,
- Ole
--- Ole Ersoy <[EMAIL PROTECTED]> wrote:
> Yes to the index of local repository part.
>
> [CONTEXT]
> My immidiate plan is to mirror the Ibiblio
> repository
> so that it&#x
Yes to the index of local repository part.
[CONTEXT]
My immidiate plan is to mirror the Ibiblio repository
so that it's local.
Then set the mirrors base directory on the plugin.
Then the plugin will produce a
repository-metadata.xml (Version 2)
per a JIRA entry I submitted.
This will be p
would they use this against an index on their local repository, or by
querying a remote archiva instance?
I do think we need to index the local metadata anyway so that the
code can be used from other tools.
- Brett
On 31/01/2007, at 3:37 PM, Ole Ersoy wrote:
Hi,
I'm going throug
Hi,
I'm going through the DefaultMetadataDiscoverer, and
noticed this todo:
* @todo Note that only the remote format is
supported at this time: you cannot search local
repository metadata due
* to the way it is later loaded in the searchers.
Review code using pathOfRemoteMetadat
I just remember why I wanted a web interface : There's no goal like
deploy:deploy-file in maven 1
And I just see that the webdav protocol doesn't seems to be supported :
http://maven.apache.org/maven-1.x/plugins/artifact/protocols.html
I think I'll have to add them on my TODO list :-( ... I
No, it's perfect.
Is there some documentation about it ?
Arnaud
On 10/12/06, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Archiva has webdav support already.
You can upload content to the repository using wagon-webdav.
Is there something else you had in mind?
- Joakim
Arnaud HERITIER wrote:
> H
1 - 100 of 184 matches
Mail list logo
