Build of 2.0.x fails

[Ralph Goers]

I'm having a problem building 2.0.x. I had a working build which I 
updated from svn last week. I updated a few minutes ago and it failed. I 
did a fresh checkout and tried it again but got the same failure.


Here is the log from the build.

Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Using settings from /home/rago2483/.m2/settings.xml
You SHOULD have a ~/.m2/settings.xml file and must contain at least the 
following information:



 /path/to/your/repository


Alternatively, you can specify -Dmaven.repo.local=/path/to/m2/repository

HOWEVER, since you did not specify a repository path, maven will use: 
/home/rago2483/.m2/repository to store artifacts locally.

Using the following for your local repository: /home/rago2483/.m2/repository
Using the following for your remote repository: 
[http://repo1.maven.org/maven2, 
http://people.apache.org/repo/m2-snapshot-repository/]

Analysing dependencies ...


Building project in 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-mini

--
Cleaning 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-mini/target...

Compiling sources ...
Compiling 34 source files to 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-mini/target/classes

Packaging resources ...
Packaging 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-mini/target/bootstrap-mini.jar 
...

--
Installing: 
/home/rago2483/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.0.9-SNAPSHOT/bootstrap-mini-2.0.9-SNAPSHOT.jar
Installing POM: 
/home/rago2483/.m2/repository/org/apache/maven/bootstrap/bootstrap-mini/2.0.9-SNAPSHOT/bootstrap-mini-2.0.9-SNAPSHOT.pom

Total time: 2 seconds
Finished at: Sun Mar 16 23:53:21 PDT 2008
Using settings from /home/rago2483/.m2/settings.xml
You SHOULD have a ~/.m2/settings.xml file and must contain at least the 
following information:



 /path/to/your/repository


Alternatively, you can specify -Dmaven.repo.local=/path/to/m2/repository

HOWEVER, since you did not specify a repository path, maven will use: 
/home/rago2483/.m2/repository to store artifacts locally.

Using the following for your local repository: /home/rago2483/.m2/repository
Using the following for your remote repository: 
[http://repo1.maven.org/maven2, 
http://people.apache.org/repo/m2-snapshot-repository/]

Analysing dependencies ...
Downloading 
http://repo1.maven.org/maven2/org/apache/maven/bootstrap/bootstrap-mini/2.0.9-SNAPSHOT/bootstrap-mini-2.0.9-SNAPSHOT.pom
Couldn't find POM - ignoring: 
http://repo1.maven.org/maven2/org/apache/maven/bootstrap/bootstrap-mini/2.0.9-SNAPSHOT/bootstrap-mini-2.0.9-SNAPSHOT.pom 
(HTTP Error: 404 Not Found)



Building project in 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-installer

--
Cleaning 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-installer/target...

Compiling sources ...
Compiling 1 source file to 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-installer/target/classes

Packaging resources ...
Packaging 
/projects/maven2/temp/maven-2.0.x/bootstrap/bootstrap-installer/target/bootstrap-installer.jar 
...

--
Total time: 1 seconds
Finished at: Sun Mar 16 23:53:23 PDT 2008
Using settings from /home/rago2483/.m2/settings.xml
You SHOULD have a ~/.m2/settings.xml file and must contain at least the 
following information:



 /path/to/your/repository


Alternatively, you can specify -Dmaven.repo.local=/path/to/m2/repository

HOWEVER, since you did not specify a repository path, maven will use: 
/home/rago2483/.m2/repository to store artifacts locally.

Using the following for your local repository: /home/rago2483/.m2/repository
Using the following for your remote repository: 
[http://repo1.maven.org/maven2, 
http://people.apache.org/repo/m2-snapshot-repository/]

Analysing dependencies ...


Building project in /projects/maven2/temp/maven-2.0.x/maven-artifact
--
Cleaning /projects/maven2/temp/maven-2.0.x/maven-artifact/target...
Compiling sources ...
Compiling 64 source files to 
/projects/maven2/temp/maven-2.0.x/maven-artifact/target/classes
Note: 
/projects/maven2/temp/maven-2.0.x/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java 
uses or overrides a deprecated API.

Note: Recompile with -Xlint:deprecation for details.
Packaging resources ...
Packaging 
/projects/maven2/temp/maven-2.0.x/maven-artifact/target/maven-artifact.jar 
...

--
Downloading 
http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-file/${wagonVersion}/wagon-file-${wagonVersion}.pom
Artifact not found at 
[http://repo1.maven.org/maven2/org/apache/maven/wagon

RE: Maven's future repository support

[Brian E. Fox]

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]

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/

[Brett Porter]

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=637324&view=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=637324&r1=637323&r2=637324&view=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 sectio

Re: Maven's future repository support

[Nigel Magnay]

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
 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: r630789 - in /maven/artifact/trunk/src: main/java/org/apache/maven/artifact/manager/DefaultWagonManager.java test/java/org/apache/maven/artifact/manager/DefaultWagonManagerTest.java

[Brian E. Fox]

>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: [VOTE] Release Maven Eclipse plugin version 2.5

[Arnaud HERITIER]

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=13593&styleName=Html&projectId=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=true&pid=11133&status=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: Mirroring by repository id? is it still sane?

[Brett Porter]

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: 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

[Brett Porter]

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?

[Nigel Magnay]

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: Mirroring by repository id? is it still sane?

[Brian E. Fox]

>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]

Maven's future repository support

[Brett Porter]

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?

[Brett Porter]

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]

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

[Brian E. Fox]

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=630789&view=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=630789&r1=630788&
>> r2=630789&view=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
>> aultWagonMa

Re: Mirroring by repository id? is it still sane?

[Jason van Zyl]

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: Mirroring by repository id? is it still sane?

[Brett Porter]

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 * 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  

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  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?

[Jason van Zyl]

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?

[Jason van Zyl]

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  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, (i

Re: Mirroring by repository id? is it still sane?

[Brett Porter]

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?

[Nigel Magnay]

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  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  entries to catch
>  >> specific ids
>  >> and redirect them to my file:// urls.
>  >> Which works, but the list is growing, I don't set up
>  >> * 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
>  >> 
>  >> and  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

Re: Mirroring by repository id? is it still sane?

[Jason van Zyl]

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  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  entries to catch  
specific ids

and redirect them to my file:// urls.
Which works, but the list is growing, I don't set up
* 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  

and  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.apa

Re: Mirroring by repository id? is it still sane?

[Nigel Magnay]

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  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  entries to catch specific ids
>  and redirect them to my file:// urls.
>  Which works, but the list is growing, I don't set up
>  * 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 
>  and  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 : http://snapshots.maven.cod

Re: [VOTE] Release Maven Eclipse plugin version 2.5

[Hervé BOUTEMY]

+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=13593&styleName=Ht
>ml&projectId=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=true&pid=11133&st
>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: [VOTE] Release Maven Eclipse plugin version 2.5

[Carlos Sanchez]

+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=13593&styleName=Html&projectId=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=true&pid=11133&status=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

[Fabrizio Giustina]

+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=13593&styleName=Html&projectId=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=true&pid=11133&status=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: Generated NOTICE files.... a solution

[Daniel Kulp]

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:
> >
> > 
> >  Apache CXF
> > 
>
> 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]

Shade MX* classes from plexus-utils?

[Benjamin Bentmann]

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: [VOTE] Release Maven Eclipse plugin version 2.5

[Fabrice Bellingard]

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=13593&styleName=Html&projectId=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=true&pid=11133&status=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]
>
>

Re: Mirroring by repository id? is it still sane?

[nicolas de loof]

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 * 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 
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  entries in
settings.xml.

Nico.