Re: Trunk has a build loop??
On Sat, Mar 15, 2008 at 9:29 PM, Wendy Smoak [EMAIL PROTECTED] wrote: With Maven 2.0.8, it fails after ~15 min complaining that the archiva-docs zip file is missing. And once I get past that, assuming the plexus runtime standalone app is still *supposed* to work, it won't start because... INFO | jvm 1| 2008/03/16 10:56:28 | Caused by: org.mortbay.util.MultiException[org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'securitySynchronization': FactoryBean threw exception on object creation; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'archivaConfiguration': FactoryBean threw exception on object creation; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'registry#commons-configuration': Post-processing of the FactoryBean's object failed; nested exception is java.lang.NoClassDefFoundError: javax/mail/Session That's very similar to a problem I'm having with Continuum... which makes me want to blame Redback since they have that in common. -- Wendy
Re: Trunk has a build loop??
On 17/03/2008, at 5:11 AM, Wendy Smoak wrote: On Sat, Mar 15, 2008 at 9:29 PM, Wendy Smoak [EMAIL PROTECTED] wrote: With Maven 2.0.8, it fails after ~15 min complaining that the archiva-docs zip file is missing. And once I get past that, assuming the plexus runtime standalone app is still *supposed* to work, it won't start because... I haven't been testing that - it probably should still work, but I'm expecting we will distribute based on the jetty + war runtime instead for 1.1. That's very similar to a problem I'm having with Continuum... which makes me want to blame Redback since they have that in common. On it's trunk? Nothing has changed so maybe it's a problem with the mail.jar on your system? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trunk has a build loop??
On Sun, Mar 16, 2008 at 1:56 PM, Brett Porter [EMAIL PROTECTED] wrote: I'm expecting we will distribute based on the jetty + war runtime instead for 1.1. And does that work? I see archiva-standalone/archiva-jetty, and MRM-688 but not much else. Executing ./archiva start makes it print a message, but nothing seems to happen... (nothing in /logs, etc.) and ./archiva stop says it wasn't running. -- Wendy
Re: svn commit: r637515 - /maven/archiva/trunk/pom.xml
Oh? Didn't know that spring-test even existed. Once we start migrating away our plexus scaffolding to spring, wouldn't we need spring too? -Joakim Brett Porter wrote: On 16/03/2008, at 2:15 PM, [EMAIL PROTECTED] wrote: * Adding spring as default dependency. Why is this needed? I would expect we only need a spring dependency in testing (which should be spring-test), and in the webapp - we're not using any interfaces? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trunk has a build loop??
On 17/03/2008, at 2:05 PM, Wendy Smoak wrote: On Sun, Mar 16, 2008 at 7:13 PM, Maria Odea Ching [EMAIL PROTECTED] wrote: Hmm, the jetty bundle should be working.. it already worked for me before. I tried it again today and was able to start it. I'm running on Linux btw. Wendy, did you get the 'Starting Archiva Web :: Jetty...' message when you did './archiva start'? Yes, but that's the only thing that happened (it printed the message, but didn't actually start.) I've been having other problems though, it's probably related to that. At least jetty:run is now working in Continuum. I'll come back around to Archiva at some point and re-check. For me, the plexus runtime works. There seems to be a bug triggered in the Jetty runtime which is two-fold. plexus-webdav is still dragged in (my fault, I'll look it up). But I also noticed a bug in the assembly descriptor too - did anyone noticed archiva jetty bakes a 53Mb ZIP file? :) It seems everything is included in repo/*, when really we just want the Jetty JARs. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Trunk has a build loop??
On Mon, Mar 17, 2008 at 11:53 AM, Brett Porter [EMAIL PROTECTED] wrote: On 17/03/2008, at 2:05 PM, Wendy Smoak wrote: On Sun, Mar 16, 2008 at 7:13 PM, Maria Odea Ching [EMAIL PROTECTED] wrote: Hmm, the jetty bundle should be working.. it already worked for me before. I tried it again today and was able to start it. I'm running on Linux btw. Wendy, did you get the 'Starting Archiva Web :: Jetty...' message when you did './archiva start'? Yes, but that's the only thing that happened (it printed the message, but didn't actually start.) I've been having other problems though, it's probably related to that. At least jetty:run is now working in Continuum. I'll come back around to Archiva at some point and re-check. For me, the plexus runtime works. There seems to be a bug triggered in the Jetty runtime which is two-fold. plexus-webdav is still dragged in (my fault, I'll look it up). But I also noticed a bug in the assembly descriptor too - did anyone noticed archiva jetty bakes a 53Mb ZIP file? :) It seems everything is included in repo/*, when really we just want the Jetty JARs. Yeah, that's my fault Brett.. All the dependencies including the transitive deps are being copied in the repo dir, I should exclude them in the assembly descriptor file. I'll correct this now. Also, some of the dependencies in there that are not jetty jars are needed for jetty jsp 2.0 support, so these need to be in the repo dir. Thanks, Deng
Re: Mirroring by repository id? is it still sane?
2008/3/16, Joakim Erdfelt [EMAIL PROTECTED]:
The approach nicolas took in MNG-3407 is strange. I don't understand
the whole {0} idea. Wouldn't it make more sense to base mirrorOf on
host or url instead?
That way the mirror section can be wrangled in a more sane way?
The idea is to force users to use a centralized mirror for repository access
(like mirrorOf* does): in a corporate env, many user don't like
uncontroled access to internet, without local controls and backups.
Using a by ID mirror for repositories, you can configure your favorite
proxy (Archiva ?) to mirror all required repositories with a dedicated URI,
and with the appropriate proxying policy.
An URL based mirroring would be far better if the settings.xml mirrorOf
element is configured with an URL and not with a repository ID: many maven
projects use inconsistent IDs for public repos (apache, apache.snapshot,
apache.snapshots...) and force to set multiple mirror entries in
settings.xml.
Nico.
Re: [VOTE] Release Maven Eclipse plugin version 2.5
I've been using the snapshot for quite a while, and it works very well. So here's my +1! Thanks Arnaud :-) -- Fabrice - [EMAIL PROTECTED] - On Sat, Mar 15, 2008 at 1:30 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/http://people.apache.org/%7Eaheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shade MX* classes from plexus-utils?
Hi, today I learned that plexus-utils is not fully shaded in the core (MNG-2898, r522313). While I can understand the requirement to share Xpp3Dom and the Xml* APIs, I wonder why the MX* implementation classes cannot be shaded. These aren't part of any public method signatures shared with plugins, aren't they? If I don't miss an aspect, we could narrow the exclusions for the shade plugin to org.codehaus.plexus.util.xml.pull.Xml* to allow plugins to benefit from updates to the MXParser and MXSerializer independently of Maven. What do you think? Benjamin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generated NOTICE files.... a solution
Quick update To get this working correctly for CXF, I need to release new versions of three things: 1) apache-jar-resource-bundle - contains the new resources. (thanks David) 2) maven-shade-plugin (1.0.1) - very minor bug fix to the transformer that merges the NOTICE files together. 3) maven-remote-resources-plugin (1.0) - I updated a few things to allow the appended resources to also be velocity processed. Example: src/main/appended-resources/META-INF/NOTICE.vm would get processed and appended to NOTICE. I need to do a bit more testing this afternoon/evening, but it looks like I'll need to do all three. Dan On Friday 14 March 2008, David Jencks wrote: On Mar 13, 2008, at 6:51 PM, Daniel Kulp wrote: David, I deployed a new snapshot, can you give that a try and make sure it's all OK? Looks great to me! - I can't get a blank line in between the project name and the notice Fixed I'm sure I tried that and it didn't work when I did it :-) - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. In the configuration for the remote-resources plugin, add something like: properties projectNameApache CXF/projectName /properties Aha! that works too many thanks david jencks Dan On Thursday 13 March 2008, David Jencks wrote: As I noted in a previous thread the current NOTICE files generated by the apache-jar-resource-bundle 1.3 are not consistent with apache policy. After some discussion on legal-discuss I've come up with a bundle that no one seems to be able to find anything seriously wrong with: we're starting to use it in geronimo. Aside from possible use by other projects I'd like to use this in an upcoming ApacheDS release, so getting it quickly into a more neutral location would be desirable. I've opened http://jira.codehaus.org/ browse/MRRESOURCES-32 and attached a patch. The basic idea is that the NOTICE file contains only the required apache notice, with no extra text, explanation, horizontal rules, or anything else. Additional required notices can be put in a NOTICE file in appended-resources and automatically appended. Dependencies are listed in an additional generated DEPENDENCIES file, by organization, and listing the license. Note that NOTICE files apply only to the exact contents of the jar in question, not to any dependencies that might be necessary to actually use the jar. For work at apache the normal situation is that the minimal NOTICE is all that is required, and if more is needed its going to be because of some special historical circumstances that can't plausibly be tracked by maven, so explicitly recording this information in a human-written additional NOTICE file is quite appropriate. There is certainly scope for some kind of aggregating bundle for assemblies that do actually contain stuff from other artifacts, such as wars, ears, tar.gzs, etc, but these are pretty clearly an entirely separate use case and likely to require considerably more work to get right. I think starting work on a separate bundle for these might be appropriate. I know of two problems in the patch, both in NOTICE.vm, and I haven't been able to figure out solutions to either: - I can't get a blank line in between the project name and the notice - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. Despite these problems I think this proposal is clearly more in line with apache policy and hope it can be accepted and released quickly. Many thanks david jencks --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5
+1 fabrizio On Sat, Mar 15, 2008 at 1:30 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5
+1 On Fri, Mar 14, 2008 at 5:30 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5
+1 Le samedi 15 mars 2008, Arnaud HERITIER a écrit : Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=Ht mlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133st atus=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
I've never thought it was sane in the first place...
I don't understand why the artifact servers (archiva et al) can't just
respond in the same way that an ordinary proxy server does, without
all this mirrorOf mucking about. Working on two or three independant
projects and my settings.xml is a bloatfest of project-specific repo
names.
I've got about 5 mirrorOf sections all pointing to a corporate
archiva server. Unfortunately (again), that's been set up in the
'default/recommended' way, whereby many remote sites are all being
proxied through one archiva repository of /internal, which IMO is
really bad, because it's possible to specify a new artifact in your
pom.xml and find it magically downloads from {remote.repo.one} via
/internal, even though you never specified {remote.repo.one} in your
pom.xml in the first place. Which is all fine until someone remote
tries to build it offsite and.. bang, it all stops working.
If the local repository was more separated out into a different format
that separated out the remote repositories that the artifacts came
from, then you could rsync directly into them anyway, which would
solve half these problems anyway... I.E
.m2/repository/local/...
.m2/repository/snapshots.maven.codehaus.org/maven2/...
etc., etc.
On Sun, Mar 16, 2008 at 5:50 AM, Joakim Erdfelt [EMAIL PROTECTED] wrote:
I was motivated by http://jira.codehaus.org/browse/MNG-3407 and some
personal headaches, mostly with dealing with working with OSS on a
laptop within restricted environments, (ie. no, or bad internet
connection, such as a service station, while waiting for your car to be
fixed.)
I have a local directory on my laptop with a central rsync and the
java.net repos, which helps a ton.
But, I've set up a long list of mirrorOf entries to catch specific ids
and redirect them to my file:// urls.
Which works, but the list is growing, I don't set up
mirrorOf*/mirrorOf intentionally, because I have separations for the
directories (so that rsync works ok for example).
I was motivated tonite to scan my central rsync mirror for repository
and pluginRepository sections to see what is actually in use, what I
found kinda confirmed my suspicions, the free form repository id naming
has blossomed into an interesting variety of choices.
Heh, this email will be good google-bot food for people searching for
maven repository mirrors.
acegi-snapshot : http://acegisecurity.sourceforge.net/repository/snapshots
activemq : http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/
activemq-repo : http://people.apache.org/repo/m2-incubating-repository
agilesque-legacy-repository : http://agilesque.net/dist
AMQ 4.0.2 :
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven2
apache.incubating : http://people.apache.org/repo/m2-incubating-repository
apache-incubator : http://people.apache.org/repo/m2-incubating-repository/
apache.incubator : http://people.apache.org/repo/m2-incubating-repository
apache-incubator-repo :
http://people.apache.org/repo/m2-incubating-repository
apache-maven-snapshots : http://cvs.apache.org/maven-snapshot-repository
apache-maven-snapshots :
http://people.apache.org/repo/m2-snapshot-repository/
apache.org : http://people.apache.org/repo/m2-snapshot-repository
apache-plugin-snapshots-repository :
http://people.apache.org/repo/m2-snapshot-repository
apache.snapshot : http://people.apache.org/repo/m2-snapshot-repository
apache-snapshot-repo : http://people.apache.org/maven-snapshot-repository
apache.snapshots : http://cvs.apache.org/maven-snapshot-repository
apache.snapshots : http://cvs.apache.org/repository
apache.snapshots : http://minotaur.apache.org/maven-snapshot-repository
apache-snapshots : http://people.apache.org/maven-snapshot-repository/
apache.snapshots : http://people.apache.org/maven-snapshot-repository
apache-snapshots : http://people.apache.org/repo/m2-snapshot-repository
apache.snapshots : http://people.apache.org/repo/m2-snapshot-repository
atanion : http://www.atanion.com/maven2
atlassian : http://repository.atlassian.com
central : http://ibiblio.org/maven2/
central : http://repo1.maven.org/maven2
central : http://www.ibiblio.org/maven2
codehaus : http://dist.codehaus.org
codehaus : http://dist.codehaus.org/
codehaus : http://repository.codehaus.org
codehaus : http://repository.codehaus.org/
CodeHaus : http://snapshots.maven.codehaus.org/maven2
codehaus-legacy-repository : http://dist.codehaus.org
codehaus-m1-repository : http://dist.codehaus.org
codehaus-m2-repository : http://repository.codehaus.org
Codehaus Maven Plugin Repository : http://dist.codehaus.org
Codehaus Maven Repository : http://dist.codehaus.org
codehaus.org : http://repository.codehaus.org/
codehaus.org : http://snapshots.repository.codehaus.org
codehaus.org : http://snapshots.repository.codehaus.org/
codehaus-plugin-repository :
Re: Mirroring by repository id? is it still sane?
On 16-Mar-08, at 11:39 AM, Nigel Magnay wrote:
I've never thought it was sane in the first place...
It is. Ultimately a repository manager should requires users to point
at one URL, period. All control must reside in the repository manager
or it's a configuration nightmare. Even if you automated the
propagation of configuration, which can be done with an SCM, or a pub/
sub model it's still a pain in the ass.
The shortest settings.xml that fully delegates to a repository manager
is still pretty lengthy but it's possible to do now, but eventually
one short URL that every developer points to should suffice.
The mirrorOf is a result of people putting repositories in their POMs
which is a horrible practice. The short term benefit of what appears
to be self-containment is a huge, fat mess. In a corporate environment
it is entire possible to know what repositories you need up-front.
Putting repositories in POMs make it impossible to have any sort of
automated promotion model and the bane of anyone's effort to have a
sane process within their organization.
In short, the baked in repos in our super POM should go away, and be
replaced by a simple configuration visible in the maven install.
Anyone should be able to change that easily, and/or control it all
from settings and ultimately it's one URL and folks delegate to a
repository manager. Repositories in POMs, hacks to repath repositories
like mirrorOf, and the * notation are a complete dead end. It needs
to be made explicit and made manageable.
I don't understand why the artifact servers (archiva et al) can't just
respond in the same way that an ordinary proxy server does, without
all this mirrorOf mucking about. Working on two or three independant
projects and my settings.xml is a bloatfest of project-specific repo
names.
I've got about 5 mirrorOf sections all pointing to a corporate
archiva server. Unfortunately (again), that's been set up in the
'default/recommended' way, whereby many remote sites are all being
proxied through one archiva repository of /internal, which IMO is
really bad, because it's possible to specify a new artifact in your
pom.xml and find it magically downloads from {remote.repo.one} via
/internal, even though you never specified {remote.repo.one} in your
pom.xml in the first place. Which is all fine until someone remote
tries to build it offsite and.. bang, it all stops working.
If the local repository was more separated out into a different format
that separated out the remote repositories that the artifacts came
from, then you could rsync directly into them anyway, which would
solve half these problems anyway... I.E
.m2/repository/local/...
.m2/repository/snapshots.maven.codehaus.org/maven2/...
etc., etc.
On Sun, Mar 16, 2008 at 5:50 AM, Joakim Erdfelt [EMAIL PROTECTED]
wrote:
I was motivated by http://jira.codehaus.org/browse/MNG-3407 and some
personal headaches, mostly with dealing with working with OSS on a
laptop within restricted environments, (ie. no, or bad internet
connection, such as a service station, while waiting for your car
to be
fixed.)
I have a local directory on my laptop with a central rsync and the
java.net repos, which helps a ton.
But, I've set up a long list of mirrorOf entries to catch
specific ids
and redirect them to my file:// urls.
Which works, but the list is growing, I don't set up
mirrorOf*/mirrorOf intentionally, because I have separations
for the
directories (so that rsync works ok for example).
I was motivated tonite to scan my central rsync mirror for
repository
and pluginRepository sections to see what is actually in use,
what I
found kinda confirmed my suspicions, the free form repository id
naming
has blossomed into an interesting variety of choices.
Heh, this email will be good google-bot food for people searching for
maven repository mirrors.
acegi-snapshot : http://acegisecurity.sourceforge.net/repository/snapshots
activemq : http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/
activemq-repo : http://people.apache.org/repo/m2-incubating-
repository
agilesque-legacy-repository : http://agilesque.net/dist
AMQ 4.0.2 :
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven2
apache.incubating : http://people.apache.org/repo/m2-incubating-repository
apache-incubator : http://people.apache.org/repo/m2-incubating-repository/
apache.incubator : http://people.apache.org/repo/m2-incubating-repository
apache-incubator-repo :
http://people.apache.org/repo/m2-incubating-repository
apache-maven-snapshots : http://cvs.apache.org/maven-snapshot-repository
apache-maven-snapshots :
http://people.apache.org/repo/m2-snapshot-repository/
apache.org : http://people.apache.org/repo/m2-snapshot-repository
apache-plugin-snapshots-repository :
http://people.apache.org/repo/m2-snapshot-repository
apache.snapshot : http://people.apache.org/repo/m2-snapshot-
repository
apache-snapshot-repo :
Re: Mirroring by repository id? is it still sane?
Have you got a description of how you think it ought to work?
I quite like the ability of downloading projects that rely on 3rd
party repos, and having them magically work without having to do
anything (which is why I have a distaste for having to go through a
validate-my-settings-and-proxy-don't-break-external-users step when
pushing project changes to outside users).
I think all I'm saying is that repository names are good, or
repository URLs are good, but names *and* URLs isn't.
On Sun, Mar 16, 2008 at 7:03 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On 16-Mar-08, at 11:39 AM, Nigel Magnay wrote:
I've never thought it was sane in the first place...
It is. Ultimately a repository manager should requires users to point
at one URL, period. All control must reside in the repository manager
or it's a configuration nightmare. Even if you automated the
propagation of configuration, which can be done with an SCM, or a pub/
sub model it's still a pain in the ass.
The shortest settings.xml that fully delegates to a repository manager
is still pretty lengthy but it's possible to do now, but eventually
one short URL that every developer points to should suffice.
The mirrorOf is a result of people putting repositories in their POMs
which is a horrible practice. The short term benefit of what appears
to be self-containment is a huge, fat mess. In a corporate environment
it is entire possible to know what repositories you need up-front.
Putting repositories in POMs make it impossible to have any sort of
automated promotion model and the bane of anyone's effort to have a
sane process within their organization.
In short, the baked in repos in our super POM should go away, and be
replaced by a simple configuration visible in the maven install.
Anyone should be able to change that easily, and/or control it all
from settings and ultimately it's one URL and folks delegate to a
repository manager. Repositories in POMs, hacks to repath repositories
like mirrorOf, and the * notation are a complete dead end. It needs
to be made explicit and made manageable.
I don't understand why the artifact servers (archiva et al) can't just
respond in the same way that an ordinary proxy server does, without
all this mirrorOf mucking about. Working on two or three independant
projects and my settings.xml is a bloatfest of project-specific repo
names.
I've got about 5 mirrorOf sections all pointing to a corporate
archiva server. Unfortunately (again), that's been set up in the
'default/recommended' way, whereby many remote sites are all being
proxied through one archiva repository of /internal, which IMO is
really bad, because it's possible to specify a new artifact in your
pom.xml and find it magically downloads from {remote.repo.one} via
/internal, even though you never specified {remote.repo.one} in your
pom.xml in the first place. Which is all fine until someone remote
tries to build it offsite and.. bang, it all stops working.
If the local repository was more separated out into a different format
that separated out the remote repositories that the artifacts came
from, then you could rsync directly into them anyway, which would
solve half these problems anyway... I.E
.m2/repository/local/...
.m2/repository/snapshots.maven.codehaus.org/maven2/...
etc., etc.
On Sun, Mar 16, 2008 at 5:50 AM, Joakim Erdfelt [EMAIL PROTECTED]
wrote:
I was motivated by http://jira.codehaus.org/browse/MNG-3407 and some
personal headaches, mostly with dealing with working with OSS on a
laptop within restricted environments, (ie. no, or bad internet
connection, such as a service station, while waiting for your car
to be
fixed.)
I have a local directory on my laptop with a central rsync and the
java.net repos, which helps a ton.
But, I've set up a long list of mirrorOf entries to catch
specific ids
and redirect them to my file:// urls.
Which works, but the list is growing, I don't set up
mirrorOf*/mirrorOf intentionally, because I have separations
for the
directories (so that rsync works ok for example).
I was motivated tonite to scan my central rsync mirror for
repository
and pluginRepository sections to see what is actually in use,
what I
found kinda confirmed my suspicions, the free form repository id
naming
has blossomed into an interesting variety of choices.
Heh, this email will be good google-bot food for people searching for
maven repository mirrors.
acegi-snapshot : http://acegisecurity.sourceforge.net/repository/snapshots
activemq :
http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/
activemq-repo : http://people.apache.org/repo/m2-incubating-
repository
agilesque-legacy-repository : http://agilesque.net/dist
AMQ 4.0.2 :
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven2
Re: Mirroring by repository id? is it still sane?
On 17/03/2008, at 6:03 AM, Jason van Zyl wrote: All control must reside in the repository manager or it's a configuration nightmare. Sorry, but I have to disagree. A repository manager is an optimisation (and best practice) in using Maven, but not a pre-requisite. Let's not forget the people that just want to build some OSS project that depends on other repositories. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
On 16-Mar-08, at 1:25 PM, Nigel Magnay wrote:
Have you got a description of how you think it ought to work?
I will do a demo sometime this week at EclipseCon, and I'm happy to
share the configuration I have. But it should be as simple as
described. One place to go, at least in a corporate environment with
100+ users it's the only way that's workable.
I quite like the ability of downloading projects that rely on 3rd
party repos, and having them magically work without having to do
anything (which is why I have a distaste for having to go through a
validate-my-settings-and-proxy-don't-break-external-users step when
pushing project changes to outside users).
Most corporate IT people don't like Maven scurrying off to some
unknown repository fetching stuff. I have had users walk up to me and
go what the hell is Maven doing?.
It is possible to make Maven do pure delegation (the mirrorOf is still
doesn't work well for snapshots and plugin repositories) and then you
can do what Tamas and I call build discovery: while a build is
executing the repository manager can collect every request to a
repository. The build could block while you approve, automatically
adding it to the list of proxied repositories, or you could just cycle
through the build, collect them all and then audit them. You could
then find the pieces in each of those repositories, download them to
your own if you don't want to proxy them and then completely lock down
the outside connections. This stuff needs to be dead simple as a lot
of people don't like Maven crawling around all over the place. So we
effectively I would encourage no repos in POMs, but we have what we
have now and you need to identify repositories in the POMs flying
through and contain them.
I think all I'm saying is that repository names are good, or
repository URLs are good, but names *and* URLs isn't.
On Sun, Mar 16, 2008 at 7:03 PM, Jason van Zyl [EMAIL PROTECTED]
wrote:
On 16-Mar-08, at 11:39 AM, Nigel Magnay wrote:
I've never thought it was sane in the first place...
It is. Ultimately a repository manager should requires users to point
at one URL, period. All control must reside in the repository manager
or it's a configuration nightmare. Even if you automated the
propagation of configuration, which can be done with an SCM, or a
pub/
sub model it's still a pain in the ass.
The shortest settings.xml that fully delegates to a repository
manager
is still pretty lengthy but it's possible to do now, but eventually
one short URL that every developer points to should suffice.
The mirrorOf is a result of people putting repositories in their POMs
which is a horrible practice. The short term benefit of what appears
to be self-containment is a huge, fat mess. In a corporate
environment
it is entire possible to know what repositories you need up-front.
Putting repositories in POMs make it impossible to have any sort of
automated promotion model and the bane of anyone's effort to have a
sane process within their organization.
In short, the baked in repos in our super POM should go away, and be
replaced by a simple configuration visible in the maven install.
Anyone should be able to change that easily, and/or control it all
from settings and ultimately it's one URL and folks delegate to a
repository manager. Repositories in POMs, hacks to repath
repositories
like mirrorOf, and the * notation are a complete dead end. It needs
to be made explicit and made manageable.
I don't understand why the artifact servers (archiva et al) can't
just
respond in the same way that an ordinary proxy server does, without
all this mirrorOf mucking about. Working on two or three independant
projects and my settings.xml is a bloatfest of project-specific repo
names.
I've got about 5 mirrorOf sections all pointing to a corporate
archiva server. Unfortunately (again), that's been set up in the
'default/recommended' way, whereby many remote sites are all being
proxied through one archiva repository of /internal, which IMO is
really bad, because it's possible to specify a new artifact in your
pom.xml and find it magically downloads from {remote.repo.one} via
/internal, even though you never specified {remote.repo.one} in your
pom.xml in the first place. Which is all fine until someone remote
tries to build it offsite and.. bang, it all stops working.
If the local repository was more separated out into a different
format
that separated out the remote repositories that the artifacts came
from, then you could rsync directly into them anyway, which would
solve half these problems anyway... I.E
.m2/repository/local/...
.m2/repository/snapshots.maven.codehaus.org/maven2/...
etc., etc.
On Sun, Mar 16, 2008 at 5:50 AM, Joakim Erdfelt [EMAIL PROTECTED]
wrote:
I was motivated by http://jira.codehaus.org/browse/MNG-3407 and
some
personal headaches, mostly with dealing with working with OSS on a
laptop within restricted environments,
Re: Mirroring by repository id? is it still sane?
On 16-Mar-08, at 3:28 PM, Brett Porter wrote: On 17/03/2008, at 6:03 AM, Jason van Zyl wrote: All control must reside in the repository manager or it's a configuration nightmare. Sorry, but I have to disagree. A repository manager is an optimisation (and best practice) in using Maven, but not a pre- requisite. Let's not forget the people that just want to build some OSS project that depends on other repositories. I think people in OSS will start using repositories managers for the convenience, but it will effectively become a pre-requisite in a production environment. Of that I have no doubt. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
The 'id' concept in Maven is fundamentally broken because it's not a
unique ID. It should be something specified in the repository itself
and validated against.
That said, the URL isn't a perfect replacement - for one it's longer,
secondly it may not be unique (such as mirrors, eg. ibiblio repo =
central), and it doesn't allow you to ever move the repository URL
(Which is the blocker).
We need to come up with the best solutions for what we have in the
2.0.x series and worry about more concise repository specification in
future versions.
Nicolas', I liked change as it allows you to be more concise in
settings while still getting all the benefits, though it does assume a
1-for-1 proxying of remote repositories in your repository manager,
which is a good practice to follow anyway IMO. If you hit an id that
you haven't accounted for, you'll likely hit a 404 in the repository
manager, which is better than just sending them all to a default route
and hoping they go to central or any other proxies configured. You can
still special case that repository in your settings as you would now,
so nothing is lost. Like Brian's proposal, it gives a bit more control
today over a feature we know needs re-thought in the future.
Are you saying you are re-considering the feature, or do you still
think it is worth having?
- Brett
On 16/03/2008, at 11:36 PM, nicolas de loof wrote:
2008/3/16, Joakim Erdfelt [EMAIL PROTECTED]:
The approach nicolas took in MNG-3407 is strange. I don't understand
the whole {0} idea. Wouldn't it make more sense to base mirrorOf on
host or url instead?
That way the mirror section can be wrangled in a more sane way?
The idea is to force users to use a centralized mirror for
repository access
(like mirrorOf* does): in a corporate env, many user don't like
uncontroled access to internet, without local controls and backups.
Using a by ID mirror for repositories, you can configure your
favorite
proxy (Archiva ?) to mirror all required repositories with a
dedicated URI,
and with the appropriate proxying policy.
An URL based mirroring would be far better if the settings.xml
mirrorOf
element is configured with an URL and not with a repository ID: many
maven
projects use inconsistent IDs for public repos (apache,
apache.snapshot,
apache.snapshots...) and force to set multiple mirror entries in
settings.xml.
Nico.
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
On 16-Mar-08, at 3:28 PM, Brett Porter wrote: On 17/03/2008, at 6:03 AM, Jason van Zyl wrote: All control must reside in the repository manager or it's a configuration nightmare. Sorry, but I have to disagree. A repository manager is an optimisation (and best practice) in using Maven, but not a pre- requisite. Let's not forget the people that just want to build some OSS project that depends on other repositories. There are people I know like Bruce Snyder and Brian who use Proximity for their own person local repository. Even for open source you're soon going to start seeing them using repository managers as the primary means of sharing their wares. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A language that doesn’t affect the way you think about programming is not worth knowing. -— Alan Perlis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r630789 - in /maven/artifact/trunk/src: main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java test/java/org/apache/maven/artifact/manager/DefaultWagonManagerTest.java
Not that it's entirely relevant, but making the assumption this is
archiva motivated is not completely out of the blue. The unit test
mentions archiva, the jira mentions archiva, the only site docs I
noticed being updated showed how this was used with archiva, the
developer that wrote committed and resolved has only 3 commits on core
and all the rest are on archiva. So I think it might be a valid
assumption...
-Original Message-
From: Joakim Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 16, 2008 12:36 AM
To: Maven Developers List
Subject: Re: svn commit: r630789 - in /maven/artifact/trunk/src:
main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java
test/java/org/apache/maven/artifact/manager/DefaultWagonManagerTest.java
Jason,
Saying that this commit is Archiva-motivated is an incorrect rush to
judgment and is insulting.
Unprovoked and inaccurate attacks against members of the committer pool
are also unhealthy to the community at large.
Brian's concerns about this change are valid as is, and need to be
addressed.
http://jira.codehaus.org/browse/MNG-3407 is the tracking point for this
feature now.
For the record, I also think this is a wonky solution to a questionable
problem.
Depending on outcome of the discussion on this list, wiki, and jira,
some consensus within the group will be made. This is the professional
approach to solving this issue.
- Joakim
Jason van Zyl wrote:
I also thought this was a little sketchy and is why I don't like the
cross project commit privs because people think it's just ok to do
this kind of thing.
Due to a limitation in Archiva not being able to deal with a single
URL (which the other repositories managers don't have a problem with)
a hack in Maven itself was done by an Archiva developer. No discussion
either. The proximity and artifactory developers don't have this
luxury and is a mild abuse of the system we have in place here IMO.
On 15-Mar-08, at 8:29 AM, Brian E. Fox wrote:
I'm -1 on this commit for several reasons:
First and foremost, there was no proposal on the wiki or any
discussion
on the dev list that I can see for this.
Second, the use case is not very clear and implementation
questionable.
If this functionality is needed for some reason, it should be brought
up
and discussed in a proposal and on the dev list. We don't just write
issues, fix them, commit and close the issue with no discussion. Also
it
seems like this change is tailored to support only one repository
manager which is concerning to me.
_-
Author: nicolas
Date: Mon Feb 25 02:18:23 2008
New Revision: 630789
URL: http://svn.apache.org/viewvc?rev=630789view=rev
Log:
MNG-3407 : improve mirrorOf to support pattern based repository URL
Modified:
maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/Def
aultWagonManager.java
maven/artifact/trunk/src/test/java/org/apache/maven/artifact/manager/Def
aultWagonManagerTest.java
Modified:
maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/Def
aultWagonManager.java
URL:
http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apac
he/maven/artifact/manager/DefaultWagonManager.java?rev=630789r1=630788
r2=630789view=diff
==
---
maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/Def
aultWagonManager.java (original)
+++
maven/artifact/trunk/src/main/java/org/apache/maven/artifact/manager/Def
aultWagonManager.java Mon Feb 25 02:18:23 2008
@@ -52,6 +52,7 @@
import org.codehaus.plexus.logging.AbstractLogEnabled;
import
org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable;
import org.codehaus.plexus.util.FileUtils;
+import org.codehaus.plexus.util.StringUtils;
import org.codehaus.plexus.util.xml.Xpp3Dom;
import java.io.File;
@@ -62,6 +63,7 @@
import java.util.Iterator;
import java.util.List;
import java.util.Map;
+import java.text.MessageFormat;
/** @plexus.component */
public class DefaultWagonManager
@@ -754,6 +756,17 @@
if ( repository == null )
{
repository = (ArtifactRepository) mirrors.get( WILDCARD
);
+if ( repository != null )
+{
+ String url = repository.getUrl();
+ if ( url.indexOf( ${mirrorOf} ) = 0 )
+ {
+url = StringUtils.replace( url, ${mirrorOf}, {0} );
+url = MessageFormat.format( url, new Object[] { mirrorOf } );
+repository = new DefaultArtifactRepository( mirrorOf, url, null
);
+ mirrors.put( mirrorOf, repository );
+ }
+ }
}
return repository;
Modified:
maven/artifact/trunk/src/test/java/org/apache/maven/artifact/manager/Def
aultWagonManagerTest.java
URL:
http://svn.apache.org/viewvc/maven/artifact/trunk/src/test/java/org/apac
he/maven/artifact/manager/DefaultWagonManagerTest.java?rev=630789r1=630
788r2=630789view=diff
Re: Mirroring by repository id? is it still sane?
On 17/03/2008, at 9:44 AM, Jason van Zyl wrote: On 16-Mar-08, at 3:28 PM, Brett Porter wrote: On 17/03/2008, at 6:03 AM, Jason van Zyl wrote: All control must reside in the repository manager or it's a configuration nightmare. Sorry, but I have to disagree. A repository manager is an optimisation (and best practice) in using Maven, but not a pre- requisite. Let's not forget the people that just want to build some OSS project that depends on other repositories. There are people I know like Bruce Snyder and Brian who use Proximity for their own person local repository. Even for open source you're soon going to start seeing them using repository managers as the primary means of sharing their wares. I'm not saying it's not a good idea. It's in my best practices slides, along with the single URL mirrorOf and using the enforcer (which I'd like to start using for weeding out repos you don't want as well). I do exactly the same as Bruce and Brian, running Archiva on my machine 24x7. It picks up all the crappy Maven ITs that depend on repository definitions that Brian is fixing, and nuisance builds that crawl out all over the place, and gives me a super-easy way to test staged releases with the addition of a flag to the build. I currently funnel everything in to a single repository for convenience and use white/blacklists, but I think with Nicolas' change in place I would move to 1-for-1 and that would make sure I knew if a build wouldn't work outside of a repository managed environment while still optimising what I have. I think this thread was about Nicolas' change specifically, so I'll start a new one to discuss what I think we need to do in Maven itself. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven's future repository support
Forking the other thread. Maven still needs to work properly without a repository manager (even if it is a good practice to use one). In my opinion, that means: - proper unique identifiers for repositories (my preference would actually be to control this by group ID, but I see too many counter examples in the Maven repositories to make this realistic - if anyone has ideas on this front please say so). - proper mirroring support (ie, specify which mirror you want to use for central, etc so you can get a nearby one out of the box, like CPAN, yum, etc type setups - I have some hand written notes from some time back sitting on my desk I can kick into the wiki) - full control over the repositories you use from the settings file. When it comes to handling repositories in POMs - I think they should still be in there, but only be a hint. ie, if the repo with that ID is not configured, Maven can intelligently tell you how to configure it if you want to, and the consequences of doing so. But I'm sure there are plenty of other ways we could deal with this. On top of this, explicit support for repository managers (that supports all of them) as a way to replace one or all of your repositories should be available and encouraged. Are these all the use cases folks see? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mirroring by repository id? is it still sane?
Nicolas', I liked change as it allows you to be more concise in settings while still getting all the benefits, though it does assume a 1-for-1 proxying of remote repositories in your repository manager, which is a good practice to follow anyway IMO. If you hit an id that you haven't accounted for, you'll likely hit a 404 in the repository manager, which is better than just sending them all to a default route and hoping they go to central or any other proxies configured. You can still special case that repository in your settings as you would now, so nothing is lost. In an Enterprise, I don't like having to rely on all the developers to have all their repo settings done correctly. It's much easier to manage a group of repositories (accessed via a single url) from the proximity side where I have control, I can change the settings and add new repos and have to roll out to an entire organization. That said, Nicolas' change is really an entirely new feature. The current code (and my proposal/patch) are about selecting a defined mirror based on a set of rules. What Nicolas' has is really a transformation of the mirror url that should be done after selection (not mixed in with). I think they can fit together, but it should be well defined and documented if we're adding it. I personally think that the whole mirror section needs to be revisted in 2.1 to add a way to really bind in a repo manager and to allow profiles in the settings to control it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
On Sun, Mar 16, 2008 at 10:35 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 16-Mar-08, at 1:25 PM, Nigel Magnay wrote: Have you got a description of how you think it ought to work? I will do a demo sometime this week at EclipseCon, and I'm happy to share the configuration I have. But it should be as simple as described. One place to go, at least in a corporate environment with 100+ users it's the only way that's workable. I quite like the ability of downloading projects that rely on 3rd party repos, and having them magically work without having to do anything (which is why I have a distaste for having to go through a validate-my-settings-and-proxy-don't-break-external-users step when pushing project changes to outside users). Most corporate IT people don't like Maven scurrying off to some unknown repository fetching stuff. I have had users walk up to me and go what the hell is Maven doing?. It is possible to make Maven do pure delegation (the mirrorOf is still doesn't work well for snapshots and plugin repositories) and then you can do what Tamas and I call build discovery: while a build is executing the repository manager can collect every request to a repository. The build could block while you approve, automatically adding it to the list of proxied repositories, or you could just cycle through the build, collect them all and then audit them. You could then find the pieces in each of those repositories, download them to your own if you don't want to proxy them and then completely lock down the outside connections. This stuff needs to be dead simple as a lot of people don't like Maven crawling around all over the place. So we effectively I would encourage no repos in POMs, but we have what we have now and you need to identify repositories in the POMs flying through and contain them. I get the central place to go, but I'm still having a hard time getting why a repository manager couldn't do all that, today, by acting as an HTTP proxy for all requests. It can look a the URL it's being requested, and say 'hmm, I cache that repo', or 'sorry, thats locked down so you can't scurry over there' or even discovering new repos at build time and adding/denying them as per config. I don't need a repository id, a mirrorOf, or any more magic than a set of URLs; HTTP and DNS already have a well-defined architecture for naming and redirection. We have an internal archiva instance. Every time a new repository gets added to a project, I have to mail out to everyone 'hey, update your settings.xml with this mirror if you are internal and you want stuff to run anything like fast'. BUT we also have external users, working from home. If someone just hacks in another repo into the /internal set in archiva, it breaks all the external users unless they make completely sure it's specified in the right place in the project pom.xmls. This is why I dislike the single URL (/internal) mapping to several external repos, it's just a recipe for failed builds. Currently, the pom file is the master record of everything about the build. You seem to be suggesting (if I'm understanding correctly) that there'd need to be a secondary, parallel configuration (file) stored in the repo manager to make your builds able to download from 3rd parties. This seems like a big retrograde step to me.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r630789 - in /maven/artifact/trunk/src: main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java test/java/org/apache/maven/artifact/manager/DefaultWagonManagerTest.java
On 17/03/2008, at 9:49 AM, Brian E. Fox wrote: Not that it's entirely relevant, but making the assumption this is archiva motivated is not completely out of the blue. The unit test mentions archiva, the jira mentions archiva, the only site docs I noticed being updated showed how this was used with archiva, the developer that wrote committed and resolved has only 3 commits on core and all the rest are on archiva. So I think it might be a valid assumption... Well, except there was no evidence in the change itself (it would work equally with artifactory using repository names that aligned to maven ids). It's not surprising that an Archiva user is going to give Archiva examples and test cases. Frankly, I think you should have given Nicolas the benefit of the doubt before charging forth to rollback his commit, and just asked the question here like I did in February when I had a suggestion about the original implementation. He did the right thing with his other fix to core, as well as multiple ones to the plugins. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
On 17/03/2008, at 10:20 AM, Nigel Magnay wrote: I get the central place to go, but I'm still having a hard time getting why a repository manager couldn't do all that, today, by acting as an HTTP proxy for all requests. It can look a the URL it's being requested, and say 'hmm, I cache that repo', or 'sorry, thats locked down so you can't scurry over there' or even discovering new repos at build time and adding/denying them as per config. I'm happy to discuss this at [EMAIL PROTECTED] if you want to see it in there - I think it's a worthwhile option, though I believe Maven should support repository management more explicitly too. mirrorOf wasn't actually designed for repository managers initially, it's just grown that feature over time. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven Eclipse plugin version 2.5
For those who have the time to review it I deployed the web site here : http://people.apache.org/~aheritier/stage/sites/maven-eclipse-plugin-2.5/index.html cheers Arnaud On Sat, Mar 15, 2008 at 1:30 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r630789 - in /maven/artifact/trunk/src: main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java test/java/org/apache/maven/artifact/manager/DefaultWagonManagerTest.java
Frankly, I think you should have given Nicolas the benefit of the doubt before charging forth to rollback his commit, and just asked the question here like I did in February when I had a suggestion about the original implementation. Given that the change amounted to about 3 lines of code and that the implementation mixed in two separate pieces of functionality, among other things, I didn't see much harm in reverting it until there was discussion on the feature and a more maintainable solution presented. Additionally the refactor I intended to do was going to completely replace the code in question, but without understanding the purpose and general agreement, I would have either had to silently drop it or try to figure it out and faithfully refactor and unit test something I wasn't sure why it was there. I figured it would be more clear if I first reverted the code, raised the question and then refactored. I don't have an issue with the feature per se, just the way it was implemented, both process and code. If we decide to implement this, I'll happily integrate it into the work I did to refactor it (in fact I had in mind this piece when I coded the patch to make it easy to drop in via a new translation method). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven's future repository support
That sounds good to me, and I see where the identifiers have come in; I think you could do without them though, and just use the repository URI as the identifier :- For 'external' mirrors, accessed directly and not through a repo manager: Say you have repo1.maven.org/maven2, and global mirrors of eu.repo1.maven.org/maven2 and us.repo1.maven.org/maven2. I think the repository doesn't need an id. There are a few options to get it to use a more localised mirror - Geo aware DNS (I think things like wikipedia are doing this). A bit hard core. - Your settings.xml file, containing a list of mirrors/redirect information based on the URI. But this settings.xml could be configured from choices either shipped with maven after installation, or (better), there might be a repo-config-SNAPSHOT.xml[1] in repo1.maven.org/maven2/repo1/maven/org/maven2/ that contains this information. Something interactive gives you the choice of manipulating your settings from the known, valid options. But a default, non-interactive build would still know where to go. For 'internal' mirrors, accessed through a repo manager: - Your install wants http://repo1.maven.org/maven2 - Your settings, as you're inside the corp firewall, say 'here is the proxy server' - The repo manager uses the appropriate strategy (including the above) to fetch or deny from repo1 or the appropriate mirror. [1] Or whatever. What would be really nice is that as well as keeping metadata about artifacts in the repository, there was a way of accessing (optionally available) metadata about the repository itself in some downloadable artifact. That way an entire 'uptodate' check for repo1 might be simply checking the ETag on 1 file. A black/whitelist of available artifacts would help preventing asking for SNAPSHOT artifacts from umpteen repos before hitting the right one; if search/index information were standardised, that could be transferred as well... On Sun, Mar 16, 2008 at 11:05 PM, Brett Porter [EMAIL PROTECTED] wrote: Forking the other thread. Maven still needs to work properly without a repository manager (even if it is a good practice to use one). In my opinion, that means: - proper unique identifiers for repositories (my preference would actually be to control this by group ID, but I see too many counter examples in the Maven repositories to make this realistic - if anyone has ideas on this front please say so). - proper mirroring support (ie, specify which mirror you want to use for central, etc so you can get a nearby one out of the box, like CPAN, yum, etc type setups - I have some hand written notes from some time back sitting on my desk I can kick into the wiki) - full control over the repositories you use from the settings file. When it comes to handling repositories in POMs - I think they should still be in there, but only be a hint. ie, if the repo with that ID is not configured, Maven can intelligently tell you how to configure it if you want to, and the consequences of doing so. But I'm sure there are plenty of other ways we could deal with this. On top of this, explicit support for repository managers (that supports all of them) as a way to replace one or all of your repositories should be available and encouraged. Are these all the use cases folks see? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r637324 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/ test/java/org/apache/maven/project/ test/resources/projects/
Hey John,
I can't see a problem one way or the other here, I just noticed you
moved the caching - can you elaborate a bit on why that was necessary,
and are you sure it won't cause any problems with caching resolved
information? It looks like it is now after interpolation, and ISTR
that giving me grief in the past.
Thanks,
Brett
On 15/03/2008, at 12:25 PM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Fri Mar 14 18:25:12 2008
New Revision: 637324
URL: http://svn.apache.org/viewvc?rev=637324view=rev
Log:
[MNG-3355] Make expressions referencing build directories resolve
and use translated paths when the project is local (NOT from a
repository, where the project.getFile() returns null). Unit test
included.
Added:
maven/components/branches/maven-2.0.x/maven-project/src/test/
resources/projects/build-path-expression-pom.xml (with props)
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/DefaultMavenProjectBuilder.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/DefaultMavenProjectBuilderTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/DefaultMavenProjectBuilder.java?rev=637324r1=637323r2=637324view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/DefaultMavenProjectBuilder.java
(original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/DefaultMavenProjectBuilder.java Fri
Mar 14 18:25:12 2008
@@ -862,14 +862,15 @@
}
processedProjectCache.put(
-createCacheKey( project.getGroupId(),
project.getArtifactId(), project.getVersion() ), project );
+
createCacheKey( project.getGroupId(), project.getArtifactId(),
project.getVersion() ), project );
-// jvz:note
+ // jvz:note
// this only happens if we are building from a source file
if ( projectDescriptor != null )
{
// Only translate the base directory for files in the
source tree
-
pathTranslator.alignToBaseDirectory( project.getModel(),
projectDescriptor.getParentFile() );
+pathTranslator.alignToBaseDirectory( project.getModel(),
+ projectDir );
Build build = project.getBuild();
@@ -883,24 +884,9 @@
project.setFile( projectDescriptor );
}
-MavenProject rawParent = project.getParent();
-
-if ( rawParent != null )
-{
-String cacheKey =
-createCacheKey( rawParent.getGroupId(),
rawParent.getArtifactId(), rawParent.getVersion() );
-
-MavenProject processedParent = (MavenProject)
processedProjectCache.get( cacheKey );
-
-// yeah, this null check might be a bit paranoid, but
better safe than sorry...
-if ( processedParent != null )
-{
-project.setParent( processedParent );
-}
-}
-
-project.setManagedVersionMap(
-createManagedVersionMap( projectId,
project.getDependencyManagement(), project.getParent() ) );
+
project.setManagedVersionMap( createManagedVersionMap( projectId,
+
project.getDependencyManagement(),
+
project.getParent() ) );
return project;
}
@@ -971,23 +957,26 @@
// We don't need all the project methods that are added over
those in the model, but we do need basedir
Map context = new HashMap();
+Build build = model.getBuild();
+
if ( projectDir != null )
{
context.put( basedir, projectDir.getAbsolutePath() );
-}
-// TODO: this is a hack to ensure MNG-2124 can be satisfied
without triggering MNG-1927
-// MNG-1927 relies on the false assumption that $
{project.build.*} evaluates to null, which occurs before
-// MNG-2124 is fixed. The null value would leave it
uninterpolated, to be handled after path translation.
-// Until these steps are correctly sequenced, we guarantee
these fields remain uninterpolated.
-context.put( build.directory, null );
-context.put( build.outputDirectory, null );
-context.put( build.testOutputDirectory, null );
-context.put( build.sourceDirectory, null );
-context.put( build.testSourceDirectory, null );
+// MNG-1927, MNG-2124, MNG-3355:
+// If the build section is present
RE: Maven's future repository support
I think there are two mutually exclusive things : 1) in an enterprise with a repo man and 2) not So 1) If a repo manager is declared, that url is used for all lookups regardless of defined repos on settings or poms. Perhaps a translation to url like Nicolas' feature is used here for repo mans/proxies that don't provide aggregation. This should be able to be declared in a profile to enable devs to work in an enterprise/with repo man and without easily (currently it's a pain to switch back and forth) 2) This is where proxies/mirrors/repo definitions come into play. Same as above, all should be in profiles. I think that mirroring by Id isn't always the greatest, but I also see no harm in continuing to support it because it can be useful in some instances. The adhoc nature of declaring repos is annoying to be sure (I'm sure everyone has seen apache.snapshot and apache.snapshots) but I don't currently have any ideas how this can be handled better. An additional mirrorOfUrl could be added to the settings so you could use mirrors by id or by url as you see fit. It would be nice to provide some automatic geo lookup but I'm not sure how that would happen. It seems like this data needs to be stored in the repo itself and then cached in the local repo. Otherwise someone would have to provide a redirection service which isn't feasible for all repos. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, March 16, 2008 7:06 PM To: Maven Developers List Subject: Maven's future repository support Forking the other thread. Maven still needs to work properly without a repository manager (even if it is a good practice to use one). In my opinion, that means: - proper unique identifiers for repositories (my preference would actually be to control this by group ID, but I see too many counter examples in the Maven repositories to make this realistic - if anyone has ideas on this front please say so). - proper mirroring support (ie, specify which mirror you want to use for central, etc so you can get a nearby one out of the box, like CPAN, yum, etc type setups - I have some hand written notes from some time back sitting on my desk I can kick into the wiki) - full control over the repositories you use from the settings file. When it comes to handling repositories in POMs - I think they should still be in there, but only be a hint. ie, if the repo with that ID is not configured, Maven can intelligently tell you how to configure it if you want to, and the consequences of doing so. But I'm sure there are plenty of other ways we could deal with this. On top of this, explicit support for repository managers (that supports all of them) as a way to replace one or all of your repositories should be available and encouraged. Are these all the use cases folks see? - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
