Re: [VOTE] Commit privs for Shane Isbell

[Joakim Erdfelt]

+1

- Joakim

Jason van Zyl wrote:

Hi,

Shane has been been working on NMaven for a couple years now, he's 
worked on the new maven-toolchain, has recently done a huge amount of 
work on cleaning up the project builder in the sandbox, and has some 
PGP tools that he would like to contribute. So overall given the time 
he's been around in the community and the the massive amount of work 
he's done lately I propose that we give him commit privs. Primarily 
because I don't want to merge his branch of 2.1 :-)


+1

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt


-
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 Plugin Tools version 2.4.2

[Joakim Erdfelt]

+1

Joakim

Vincent Siveton wrote:

+1

Vincent

2008/6/22 Dennis Lundberg <[EMAIL PROTECTED]>:
  

Hi,

We solved 19 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11139&styleName=Html&version=14166

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11139&status=1

Staging repo:
http://people.apache.org/~dennisl/staging-repo/plugin-tools/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


--
Dennis Lundberg

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

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Checkstyle plugin version 2.2

[Joakim Erdfelt]

+1

Dennis Lundberg wrote:

Hi,

It's been over two years since the last release, so let's do this :-)

We solved 31 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&styleName=Html&version=12489 



There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1 



Staging repo:
http://people.apache.org/~dennisl/staging-repository/

Staging site:
http://maven.apache.org/plugins/maven-checkstyle-plugin-2.2/

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]

Mirroring by repository id? is it still sane?

[Joakim Erdfelt]

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.codehaus.org/maven2/
codehaus-snap : http://snapshots.repository.codehaus.org/
codehaus-snapshot-repo : http://snapshots.repository.codehaus.org/
codehaus-snapshots : http://snapshots.maven.codehaus.org/maven2
codehaus-snapshots : http://snapshots.repository.codehaus.org
codehaus-snapshots : http://snapshots.repository.codehaus.org/
codehaus.snapshots : http://snapshots.repository.codehaus.org
dist.codehaus.org : http://dist.codehaus.org
dtddoc : http://dtddoc.sf.net/maven2
fabric3 : http://www.fabric3.org/snapshots
gleamynode-m1-repository : http://gleamynode.net/dev
gwt-maven-repo : http://gwt-maven.googlecode.com/svn/trunk/mavenrepo
ibiblio : http://ibiblio.org/maven2
java.net : https://maven-repository.dev.java.net/nonav/repository
java.net : https://maven-repository.dev.java.net/repository
java.net repository : 
https://maven-repository.dev.java.net/nonav/repository/

jetty6-releases : http://www.mortbay.org/maven2/release
jetty6-snapshots : http://www.mortbay.org/maven2/snapshot
jetty-repository : http://repository.codehaus.org/
jetty-snapshot-repository : 
http://jetty4.inetu.net/home/ftp/pub/maven2/snapshot

jetty-snapshot-repository : http://snapshots.repository.codehaus.org/
jibx : http://jibx.sourceforge.net/maven2/
jibx.sf.net : http://jibx.sf.net/maven
jibx.sf.net : http://jibx.sf.net/maven2
m2-snapshot-repository : 
http://people.apache.org/repo/m2-snapshot-repository

mapasuta.repo : http://mapasuta.sf.net/maven/repo
maven2 : http://repo1.maven.org/maven2
maven2-reposi

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

[Joakim Erdfelt]

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
aultWagonManagerTest.java
URL:
http://svn.apache.org/viewvc/maven/artifact/trunk/src/test/java/org/apac
he/maven/artifact/manager/DefaultWagonManagerTest.java?rev=630789&r1=630
788&r2=630789&view=diff

==
---
maven/artifact/trunk/src/test/java/org/apache/maven/artifact/manager/Def
aultWagonManagerTest.java (original)
+++
maven/artifact/trunk/src/test/java/org/apache/maven/artifact/manager/Def
aultWagonManagerTest.java Mon Feb 25 02:18:23 2008
@@ -56,6 +56,15 @@
wagonManager = (WagonManager) lookup( WagonManager.ROLE );
}

+ public void testMappedMirror()
+ throws Exception
+ {
+ DefaultWagonManager manager = (DefaultWagonManager) wagonManager;
+ manager.addMirror( "wildcar", "*",
"http://archiva/repository/${mirrorOf}"; );
+ assertEquals( "http://archiva/repository/central";, manager.getMirror(
"central" ).getUrl() );
+ assertEquals( "http://archiva/repository/apache.snapshots";,
manager.getMirror( "apache.snapshots" ).getUrl() );
+ }
+
public 

Re: Wagon changes and WebDAV

[Joakim Erdfelt]

Jason van Zyl wrote:


On 28-Feb-08, at 1:35 PM, Brett Porter wrote:



On 29/02/2008, at 5:51 AM, Jason van Zyl wrote:


I'm going to roll back all the WagonDAV changes as

1) As we discussed about extensions on the list that for deployment 
the required libraries necessary for deployment should be 
dependencies listed in the deployment plugin and not wired into the 
core.


2) The wagons can now be picked up with the dynamic collections so 
that's also not necessary to bind them in there.


Is this already in place? The use case is for deploy:deploy-file, so 
(1) is not an option.




Dynamic collections have been there for a while. And why is 
deploy:deploy-file a concern, and for webdav. This will be the case 
for all providers. FTP deploy doesn't work out of the box either, 
should be start adding everything because they need a POM to use 
deploy file with FTP. Probably not.


The other issue is why isn't just plain PUT fine. I don't know how it 
ever came to be that we pushed WebDAV.


Plain PUT does not work if the directory doesn't exist yet. (That's part 
of the HTTP spec).
You need something to create the directory (or "Collection" in WebDAV 
Terms), this is the MKCOL method.


While it is true that FTP is also a provider, it should be painfully 
obvious that all existing repository manager implementations support 
WebDAV.  And it's a favorite deployment technique in corporate 
environments for the security aspects alone. 

Sure you could accomplish the same thing with SSH, but how many people 
do you find asking for deploy:deploy-file with ssh in the users list?  
In many corporations I've been involved in SSH is fine for many tasks, 
but not repository management for the rank and file or for the 
continuous integration server.  (Typically due to political and 
maintenance reasonsnot for technical ones)


We have clear trend established with the users (in the mailing list and 
jira) that webdav is a popular choice, and the deploy:deploy-file is 
painful without it being in core, and also no option to build a custom 
client with it embedded (classloader yech, yada yada).  bringing it in 
via the command line isn't an option.  So we're left with creating a pom 
just to use deploy:deploy-file with webdav.




As I said before - that's fine, but it should be working before the 
first alpha so that there's no regression in functionality.




It's never been there so it's not a regression because no one has ever 
used it or done it. If you need a POM to deploy-file that's fine. 
We're not going to start pushing in all the providers so people can do 
this. Pushing it all in the core, sprinkling the logic everywhere we 
need to handle the JARs especially the httpclient mess of commons-* is 
not very appealing.


The work that brett did for in wagon-http (not the lightweight one) 
cleans up the commons-* stuff significantly (shading the commons-* tree 
into the org.apache.maven.wagon.common.* package space).  In a local 
snapshot build with maven 2.0.x using this new wagon-http over the 
existing wagon-http-lightweight found it only added about 300k to the 
size of the distro along with making for a more friendly http provider 
when dealing with oddball auths, like the one i'm experiencing now that 
does not allow for preemptive auth, only challenge / response auth with 
the returned cookie from the challenge, or being able to use NTLM auth.  
or even being able to use DIGEST auth.  something that the 
wagon-http-lightweight really does not do effectively.


Then there's also the performance work coming out of Don Brown, which 
utilizes the wagon-http provider too.


There is a clear trend and desire for this work / feature.  Don't toss 
is aside just yet.  Lets see where this discussion leads, and lets get 
some raw numbers from the mailing list to aide us in the decision.  
Meanwhile I'll keep plodding along with the wagon-http infused maven for 
a few more weeks to see if anything crops up.  (I like it, it seems to 
be faster, but I'm sure that's just a subjective perception of it)







3) Merging webdav into the main Wagon is a bad idea. Leave the 
simple provider alone and the more complicated ones are easy to add 
as dependencies or be loaded dynamically.


I assume you are referring to Joakim's change which is completely 
separate and on a branch, and so there's nothing to revert there?

Yup, this is all in a branch, no changes occurred in trunk.

It was created to prove a concept, let discussion start, show that you 
can actually bring in the webdav support in a lightweight touch, 
_without_ changing the GET / PUT logic in wagon-http, only supplementing 
it with a webdav MKCOL for PUT failures and providing a more accurate 
file listing in the .fileList() wagon methods for use in the various 
plugins that use that method.


I have introduced 1 non-webdav improvement in wagon-http, an improved 
LinkParser for html content (using nekohtml + dom + java.net.URI, vs 
current trunk which uses jtidy 

Re: [discuss] Archiva TLP proposal

[Joakim Erdfelt]

Fabrice Bellingard wrote:

On Mon, Feb 25, 2008 at 3:04 AM, Brett Porter <[EMAIL PROTECTED]> wrote:

  

Ok, seems there is some interest in putting together a proposal. I'm
going to follow the same format we used at Continuum last month.

Before we continue to vote on a proposal to send to the board, we need
to:

1) Decide on a charter for the project.

"the creation and maintenance of open-source software related to ..."




Here's my try :-)

"The Apache Archiva project is an extensible repository management software
that helps taking care of your own personal or enterprise-wide artifact
repository. It offers several capabilities, amongst which remote repository
proxying, build artifacts storage, delivery and indexing, extensible
scanning functionality, and many more."
  


+1 from me.



2) Nominate a chair to put in the proposal
  

I would like to nominate Deng as the chair of the project. I think the
work she has done in making sure releases happened consistently,
answering users questions, and following up contributions has
contributed a lot to the growth of the project recently.

Are there any other nominations or seconds?




Agree, Deng has done a really good job around Archiva, which makes her an
excellent candidate for the chair of the projet. :-)
Joakim has also been involved a lot, and could therefore also be a good
candidate, IMO.
  


I'm honored that you would consider me, but I'm going to have to decline 
the PMC chair for Archiva at this time.
My life, job, and house construction is eating far too much time to be 
an effective PMC chair.




  

3) Agree on the initial committers and PMC list

I have the current committers list as:
Maria Odea Ching ([EMAIL PROTECTED])
Fabrice Bellingard ([EMAIL PROTECTED])
Nicolas de Loof ([EMAIL PROTECTED])
Joakim Erdfelt ([EMAIL PROTECTED])
Arnaud Heritier ([EMAIL PROTECTED])
Dennis Lundberg ([EMAIL PROTECTED])
Jesse McConnell ([EMAIL PROTECTED])
Brett Porter ([EMAIL PROTECTED])
Edwin Punzalan ([EMAIL PROTECTED])
Carlos Sanchez ([EMAIL PROTECTED])
Wendy Smoak ([EMAIL PROTECTED])
John Tolentino ([EMAIL PROTECTED])
Emmanuel Venisse ([EMAIL PROTECTED])




+1
  


+1 to this list.
Is this a list of existing commiters in the project only?
Would it be inappropriate to get James Dumay involved in this too?



  

Cheers,
Brett




Thanks for starting this, Brett.

Fabrice

  


-  Joakim

Re: trunk & shading

[Joakim Erdfelt]

I took a stab at making wagon-http WebDAV aware (WAGON-99).
I have this experimental code in the following branch.

https://svn.apache.org/repos/asf/maven/wagon/branches/wagon-http-with-webdav

It needs some more work and unit testing, but the bones are there.

This branch adds the 2 missing HttpMethods (MKCOL, and PROPFIND) to the 
wagon-http client, makes the client inspect the server to see If it has 
WebDav and then uses WebDav specifics for PUT (with MKCOL) and 
FileListing (with PROPFIND).
This branch also eliminates the need for wagon-webdav (yay! one less 
release to worry about)
This branch also eliminates the need for wagon-http-shared (yet another 
release eliminated)


- Joakim

Brett Porter wrote:


On 27/02/2008, at 12:59 PM, Jason van Zyl wrote:



this didn't give me any luck unfortunately. I'm not entirely 
comfortable tossing commons-logging into the root classloader at 
this stage without tying it into the plexus logging properly, so I 
think the pre-shaded webdav library is the way to go at this point 
(it's essentially the same thing).




No the replacement for commons logging, so there is no commons 
logging jar in the root classloader.


You're right - that is what I'd tried but I thought it sat alongside 
commons-logging. It's working as a complete replacement so I've 
committed that.


Should slf4j give any grief with plugins, I also attached a patch to 
MNG-2664 that uses a pre-shaded webdav library instead.


- 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: r630338 - in /maven/plugins/trunk/maven-deploy-plugin: pom.xml src/main/java/org/codehaus/

[Joakim Erdfelt]

I still use 2.0.5 daily at the office.
I do have 2.0.7 and 2.0.8 installed too, but there's some bad juju (re: 
bugs) starting in 2.0.6+ WRT corporate repositories, wagon lightweight 
http, non-projects (archetype, install-file, deploy-file, eclipse, 
etc...) and also plugin resolution.  So we are stuck on 2.0.5 for the 
time being.


John Casey has recently closed many of the bugs that we are having with 
2.0.6+, but there hasn't been a release of 2.0.x yet with those fixes in it.
I've been using a build from the maven-2.0.x branch for a week or so 
that seems to address many of the issues, but haven't fully fleshed out 
the use cases yet.


- Joakim

Olivier Lamy wrote:

Hi,
Ok I understand the point (I have reverted the commit).
But 2.0.6 has been released ~ 1 year ago.
What could be the time to wait to add a core prerequisite ? (Note :
the jar plugin have this prerequisite and I haven't yet seen user
complaining).

I don't know how many people use mvn before 2.0.6 currently (except
the guys who wants to deploy plexus-utils ;-) but they could easily
lock the plugin version).
It's difficult to have such statistic.

--
Olivier

2008/2/23, Jason van Zyl <[EMAIL PROTECTED]>:
  

That's probably not a good idea as it's a plugin in the default
 lifecycle which means now that anyone using anything before 2.0.6 is
 going to get cut off from any improvements.

 It's really a policy decision but I think it would be a good idea to
 try and keep the default lifecycle plugins working as far back to 2.0
 as we can. We just have to live with the cruft in this case.

 On 22-Feb-08, at 2:25 PM, [EMAIL PROTECTED] wrote:

 > Author: olamy
 > Date: Fri Feb 22 14:25:07 2008
 > New Revision: 630338
 >
 > URL: http://svn.apache.org/viewvc?rev=630338&view=rev
 > Log:
 > upgrade to p-u 1.5
 > remove duplicated classes from p-u
 >
 >
 > Removed:
 >maven/plugins/trunk/maven-deploy-plugin/src/main/java/org/codehaus/
 > Modified:
 >maven/plugins/trunk/maven-deploy-plugin/pom.xml
 >
 > Modified: maven/plugins/trunk/maven-deploy-plugin/pom.xml
 > URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-deploy-plugin/pom.xml?rev=630338&r1=630337&r2=630338&view=diff
 > =
 > =
 > =
 > =
 > =
 > =
 > =
 > =
 > ==
 > --- maven/plugins/trunk/maven-deploy-plugin/pom.xml (original)
 > +++ maven/plugins/trunk/maven-deploy-plugin/pom.xml Fri Feb 22
 > 14:25:07 2008
 > @@ -30,7 +30,7 @@
 >   2.4-SNAPSHOT
 >   2004
 >   
 > -2.0
 > +2.0.6
 >   
 >   
 > JIRA
 > @@ -68,6 +68,11 @@
 >   org.apache.maven
 >   maven-artifact
 >   2.0.6
 > +
 > +
 > +  org.codehaus.plexus
 > +  plexus-utils
 > +  1.5
 > 
 > 
 >   org.apache.maven
 >
 >

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 jason at sonatype dot com
 --

 We know what we are, but know not what we may be.

 -- Shakespeare




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

  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shall we branch?

[Joakim Erdfelt]

Big +1 from me too.

- Joakim

Wendy Smoak wrote:

There was some discussion on IRC last night about branching Archiva
1.0 to allow trunk to move on as 1.1.

Thoughts?

  

Re: [vote] separate issues@ list

[Joakim Erdfelt]

+1

Was wondering what this was about, as I have a .procmailrc filter 
already to do this for me.

Sure. formalize it!

- Joakim

Brett Porter wrote:
per the thread on [EMAIL PROTECTED] - should Archiva have it's own 
[EMAIL PROTECTED] list?


[ ] +1
[ ] 0
[ ] -1

Cheers,
Brett

Re: [vote] Release Archiva 1.0

[Joakim Erdfelt]

+1 Release it!

- Joakim

Maria Odea Ching wrote:

Hi Everyone,

The Archiva 1.0 release candidate has been prepared. Regressions for m1
proxy requests found in 1.0-beta-4 have been fixed and the important
documents for the site have been completed.

You can take a look at the release notes for Archiva 1.0 here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=12113&styleName=Text&projectId=10980&Create=Create


While the binaries, including the sources, signatures and checksums, can be
downloaded here:

http://people.apache.org/builds/maven/archiva/1.0/


Everyone is encouraged to vote and give their feedback. Please make sure to
test it before voting ;-)

[ ]  +1  Release it!
[ ]   0
[ ]  -1  Don't release it, because...

The vote will be open for 72 hours. So, cast your votes now..


Thanks,
Deng

  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: [vote] Nicolas de Loof as a committer

[Joakim Erdfelt]

+1 from me.

- Joakim

Brett Porter wrote:
I'd like to call a vote for Nicolas de Loof as a committer, based 
primarily on his work for Archiva, but also from being active in the 
general Maven community for quite some time. He has been relentlessly 
testing and identifying issues and providing patches recently.


+1 from me

- Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: more thoughts on proxy logging

[Joakim Erdfelt]

OK, what I got from this is some proxy logging guidelines.

1) Always include the source repository id
2) Always include the resource being requested
3) Use DEBUG severity level for normal (happy path) events.
4) Use INFO severity level for whitelist / blacklist rejections.
5) Use INFO severity level for transfer rejections due to policy failures.
6) Use WARN severity level for connection / transfer errors from
java.io.* or wagon.

Some questions that are left.
* Do we consider the target repository id to be important to always log?
* Do we show the resource (the path) or the artifact (the
group:artifact:version:classifier:type key) in the log?
* Do we show in the log a "whats left" list of repositories that
can/will be checked next? (and indications if no more proxies are being
checked?)
* Do we log the network proxy setting? that it is being used?
   If so, then at what severity level?

Note: I'm considering creating a ProxyEvents object (or just methods in
DefaultProxyConnector)  to maintain a consistent logging experience.
.logEvent(String sourceRepoId, String targetRepoId, String resource,
String msg)
.logRejection(String sourceRepoId, String targetRepoId, String resource,
String rejectionType, String reason)
.logError(String sourceRepoId, String targetRepoId, String resource,
String where, String reason, boolean continuing)

Idea here it to abstract the logging, and force/remind the developer to
include certain information, and make the formatting consistent (to have
a consistent user experience)

wdyt?

- Joakim

Brett Porter wrote:
> Hi,
>
> I've been trying to figure out how best to address proper diagnostic
> info in proxy logging after finding myself confused when it failed
> recently. I think this can hold until 1.1, but I started a JIRA for
> tracking (MRM-588) and hoped we could discuss it here.
>
> Here is the summary:
>
> I would like to open discussion for what exactly needs to be logged,
> and at what level, for proxy issues to be effectively diagnosed. With
> the current configuration, I was unable to pinpoint some problems easily.
>
> Some thoughts:
>
> * don't talk about policies, but state what is happening
> * always include the artifact and repository requested
> * log more if it results in a NotFoundException
> * condense information onto fewer lines where possible (if there
> are concurrent requests, without an NDC these will start getting mixed
> up in the logs)
>
> Here are my thoughts:
>
> DEBUG Artifact [x/y/z.jar] will not be requested from remote
> repository [foo] as it didn't match whitelist items
> DEBUG Artifact [x/y/z.jar] will not be requested from remote
> repository [foo] as it matched blacklist item x/**
> INFO Artifact [x/y/z.jar] requested from managed repository
> [internal], checking remote repositories [central,java.net], excluding
> remote repositories [foo]
>
> Then:
> INFO Artifact [x/y/z.jar] retrieved from remote repository [central],
> skipping others
> or
> INFO Artifact [x/y/z.jar] not retrieved as it failed post-download
> policy [bar-policy] (include reason)
>
> And so on...
>
> Thoughts?
>
> An open question is what level to log this at: I feel that it should
> be at INFO, but that might be too noisy by default. Perhaps the right
> thing to do here is to add a connector configuration property that
> says whether to log all requests (and if not, only log at debug level).
>
> Cheers,
> Brett
>
> -- 
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>
>

Re: Site and parent changes

[Joakim Erdfelt]

+1
I like it!
I think we'll need a link to "other downloads" on that slideout download
box, tho.

- Joakim

Brett Porter wrote:
> As I alluded to in my other mail, I did some work on making a top
> level site. More work is needed, and I need to drag in the project
> documentation itself, but I thought it'd be good to get some feedback.
> It's all out of the way for right now.
>
> It looks like this:
> http://people.apache.org/~brett/new-archiva-site-mockup/
>
> (don't mind the design so much - more about the content and emphasis,
> though do note the easy popup for downloads when moused over :).
>
> It's meant to be very simple, and once you download, you go off to the
> documentation for the latest version for the guide. The documentation
> will have the left nav that was introduced on trunk and be basically
> self contained. You'll be able to get to docs for older versions if
> you desire.
>
> BTW, I also started to prepare trunk for making documentation instead
> of a site (that can be bundled up and deployed at /docs/1.0 as I
> discussed in the other mail). For this, I also introduced a shared
> parent POM for Archiva in /parent. I haven't flipped trunk to use it
> yet though. Any objections to me doing that? I can create an externals
> archiva-all that will pull in trunk, parent and site if that helps.
>
> Thoughts, flames? All totally undoable, but I think this is the way to
> go :)
>
> Cheers,
> Brett
>
> -- 
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>
>

Re: ApacheCon/OSSummit roll call!

[Joakim Erdfelt]

[X] I'll be at ApacheCon US in Atlanta

Man, I owe so many beers to other maven developers that I better be sure 
to free up some room on my credit cards ...


- Joakim

Brett Porter wrote:
I know several folks are presenting and will definitely be there, but 
I thought it might be good to send a shout out and see who is coming 
along? Hopefully we'll get some opportunities for getting together 
around the hackathon/code-a-ramas.


I'm also interested in organising a Maven project BOF at each. Any 
thoughts?


[ ] I'll be at ApacheCon US in Atlanta
[ ] I'll be at OSSummit Asia in Hong Kong

I'm planning to be at both with bells on.

Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[DISCUSS] [MRM-564] Audit Logging.

[Joakim Erdfelt]

A change was made to audit logging today (re: MRM-564)

The audit.log is now generated via a log4j logger (not direct java.io 
usage).

The output contains the following structure.

"{timestamp} {repository_id} {user_id} {remote_ip} \"{resource}\" 
\"{action}\""


Example output:

2007-11-08 11:18:43 internal joakim 127.0.0.1 
"org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.jar" "Created 
File (proxied)"
2007-11-08 11:18:43 internal joakim 127.0.0.1 
"org/codehaus/plexus/plexus-compiler-manager/1.5.3/plexus-compiler-manager-1.5.3.jar" 
"Created File (proxied)"
2007-11-08 11:19:00 internal joakim 127.0.0.1 
"org/apache/maven/maven/2.0.6/maven-2.0.6.pom" "Created File (proxied)"
2007-11-08 11:19:01 internal joakim 127.0.0.1 
"org/apache/maven/maven-settings/2.0.6/maven-settings-2.0.6.pom" 
"Created File (proxied)"

2007-11-08 11:32:06 internal joakim 127.0.0.1 "/net" "Created Directory"
2007-11-08 11:32:06 internal joakim 127.0.0.1 "/net/erdfelt" "Created 
Directory"
2007-11-08 11:32:06 internal joakim 127.0.0.1 "/net/erdfelt/sysutils" 
"Created Directory"
2007-11-08 11:32:06 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1" "Created Directory"
2007-11-08 11:32:06 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.jar" "Created File"
2007-11-08 11:32:07 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.jar.md5" "Created File"
2007-11-08 11:32:07 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.jar.sha1" "Created File"
2007-11-08 11:32:08 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.pom" "Created File"
2007-11-08 11:32:08 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.pom.md5" "Created File"
2007-11-08 11:32:08 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/1.1/sysutils-1.1.pom.sha1" "Created File"
2007-11-08 11:32:09 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/maven-metadata.xml" "Created File"
2007-11-08 11:32:09 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/maven-metadata.xml.md5" "Created File"
2007-11-08 11:32:09 internal joakim 127.0.0.1 
"/net/erdfelt/sysutils/maven-metadata.xml.sha1" "Created File"


This is hooked up into the ProxiedDavServer component at the moment, but 
in a discussion with Wendy on irc, I identified a few more potential 
places to generate audit log from ...


1) Repository Configuration Create
2) Repository Configuration Edit
3) Repository Configuration Delete
4) Proxy Connector Create
5) Proxy Connector Edit
6) Proxy Connector Delete
7) Metadata Merge
8) Auto-Remove Consumer
9) Auto-Rename Consumer
10) Snapshot Repository Purge Consumer
11) Scan Start
12) Scan End

We both agreed that #10 (Snapshot Repository Purge Consumer) is an 
obvious one to hook up.

What are the feelings of the rest of developers and users of archiva?
What else should be logged?
What kind of guidelines should be placed on audit logging?

Also, what should we use in the log field for "user id" and "remote ip" 
when logging from consumers?
One idea would be to use "[consumer]" or "[purge]" style/format for the 
"user id" field, and "0.0.0.0" for remote ip in this situation.


Comments?

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

[MRM-435] Need to review repository defaults

[Joakim Erdfelt]

I'm working through the open jiras and i keep coming across this one.

[MRM-435] Need to review repository defaults
Description: we should review the use of the appserver path as the 
default location, as it is not particularly friendly to seting up as a 
standalone web application. I believe there is insufficient error 
handling to correct this situation if the user forgets to first set the 
variables during installation.


What kind of resolution is being proposed for this?

I think this one can be closed.
As ...
1) The logging has been updated.
2) The repositories screen shows a big fat red error box if the 
directory is invalid, can't be found, can't be created, or can't be 
written to.


What else is there?

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

archiva-backend-security branch.

[Joakim Erdfelt]

I'm wrapping up work on the archiva-backend-security branch.
I'll need a review (or two) before I can merge this code back into trunk.

Fixed Issues (in trunk):
MRM-569 - Browse shows results for all repositories, regardless of security.
MRM-516 - Search results return results for all repositories, regardless 
of security.


Thanks,

--
- Joakim Erdfelt
 [EMAIL PROTECTED]

Re: MRM-549 & MRM-547 : Proxy Connector Policy settings.

[Joakim Erdfelt]

Brett Porter wrote:

On 01/11/2007, at 10:01 AM, Joakim Erdfelt wrote:


IGNORED is a universal setting that means ... "This policy is ignored."
It can be applied to any policy.

Changing IGNORED to ALWAYS is makes no sense for the other policies.


I wasn't suggesting this for anything but release and snapshots (it 
was an eg, not an ie). For cache: it's a yes/no answer, and for 
checksum ignore is valid.



What about using SKIP in place of IGNORED?
What about using REJECT in place of DISABLED?


I'm still confused what that really means.

In the first set, to me, SKIP means "don't ever check for updates", 
since the context is when to check for updates, right? But I think 
you're saying it means "skip the check about whether to check for 
updates and check for updates anyway".


If the question to be asked is "how often should Archiva check for 
updates"? SKIP, DISABLED, IGNORED, REJECT are not valid answers in the 
context of what happens. ALWAYS and NEVER would be.


Or am I asking the wrong question? If so, what is a question you can 
ask and have each option as an answer for that matches the current 
behaviour?


Likewise:

* Should I cache failures? YES or NO. Or it could be "What should I do 
when I encounter a failure?" CACHE or DON'T CACHE. But 
IGNORED/SKIP/DISABLED/REJECT don't make sense in this context (at 
least with the given behaviour)


* What should I do when a checksum is invalid? IGNORE, FIX or FAIL.

Make sense?

No.

Making no common ground between the options is also confusing.
There needs to be a common "DO NOT USE" or "IGNORED" option.
But I can release that opinion in favor of a clear and defined set of 
values.
So far, all I'm getting is handwaving, big picture stuff, not a defined, 
concrete, list to work off of.

As I intepret your last comments, I see the list now as the following ...

Releases
 (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
 (proposed) SKIP, ONCE, HOURLY, DAILY, REJECT
Snapshots
 (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
 (new) SKIP, ONCE, HOURLY, DAILY, REJECT
Cache-Failures
 (old)  IGNORED, CACHED
 (new) NO, YES
Checksum
 (old)  IGNORED, FIX, FAIL
 (new) SKIP, FIX, FAIL

Any more changes?

- Joakim

Re: MRM-549 & MRM-547 : Proxy Connector Policy settings.

[Joakim Erdfelt]

IGNORED is a universal setting that means ... "This policy is ignored."
It can be applied to any policy.

Changing IGNORED to ALWAYS is makes no sense for the other policies.

Releases
  (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
  (new) ALWAYS, ONCE, HOURLY, DAILY, DISABLED
Snapshots
  (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
  (new) ALWAYS, ONCE, HOURLY, DAILY, DISABLED
Cache-Failures
  (old)  IGNORED, CACHED
  (new) ALWAYS, CACHED
Checksum
  (old)  IGNORED, FIX, FAIL
  (new) ALWAYS, FIX, FAIL

Using the logic that we should use wording that applies the artifact, 
(which itself is misleading, as these affect metadata too), then the 
DISABLED option should be changed too.


I have a feeling that we are confusing the meanings of IGNORED and DISABLED.

What about using SKIP in place of IGNORED?
What about using REJECT in place of DISABLED?

So it would become 

Releases
  (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
  (proposed) SKIP, ONCE, HOURLY, DAILY, REJECT
Snapshots
  (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
  (new) SKIP, ONCE, HOURLY, DAILY, REJECT
Cache-Failures
  (old)  IGNORED, CACHED
  (new) SKIP, CACHED
Checksum
  (old)  IGNORED, FIX, FAIL
  (new) SKIP, FIX, FAIL

WDYT?

- Joakim

Brett Porter wrote:

I'd say 2)

please just change "ignored" to a value that interacts with the 
artifact (eg, always) instead of the policy, since that's what all the 
other values do.


On 23/10/2007, at 1:17 PM, Joakim Erdfelt wrote:

There seems to be some confusion on the settings, defaults values, 
meanings, purpose, etc...


http://jira.codehaus.org/browse/MRM-549
* MRM-549 : proxy connectors: no "always" option for releases and 
snapshots policies


http://jira.codehaus.org/browse/MRM-547
* MRM-547 : proxy connectors: cache failures options are confusing

http://docs.codehaus.org/display/MAVENUSER/Archiva+Proxy+Policies

I'd like to hear from you about what is bad about the current settings?

What is good about the current settings?

Some options on how to correct this?
 (my 2 bits)
 1) Create a sidebar on the proxy connector screen detailing the 
meaning of the policy settings.
 2) Change the policy setting values to make more sense to the 
largest body of individuals.


I'd like to get these closed out, it'll be a simple fix, but the 
decision needs discussion first.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]



--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: svn commit: r583412 [1/8] - in /maven/archiva/trunk: archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/ archiva-base/archiva-configuration/src/main/java/org/a

[Joakim Erdfelt]

Brett Porter wrote:


On 19/10/2007, at 4:58 AM, Joakim Erdfelt wrote:






 /**
  * Purge the repo. Update db and index of removed artifacts.
  *
  * @param artifactFiles
  * @throws RepositoryIndexException
  */
-protected void purge( File[] artifactFiles )
+protected void purge( Set references )


Was the behaviour of this changed? It looks like we now go File -> 
ArtifactReference -> File which seems redundant?


Manipulating the repository directly via file references has caused 
many bugs.
This is more of an interim step, while we work out the interface for 
RepositoryContent to be more useful.
I expect things like this to go away completely once we do the 
webservices work in post 1.0
For now, it's not harming anything, and just validates that what you 
are attempting to purge is actual repository content.


This is similar to the discussion recently started around actions on 
the repository being done via the RepositoryContent interface, not 
not via direct filesystem manipulation. See that thread.


My concern is that the first time I tried to use the purge it was 
broken. I haven't had problems since, but I don't think the changes 
have been tested enough. Did you explicitly fix something since, or do 
we need to go back and check the testing?






From what I can tell, you added functionality to delete support 
files (great!), but it wasn't referenced in the commit log or a 
JIRA. It's hard to track when multiple changes like that occur - can 
you clarify?


Something is not working, since as soon as I run it I get this:

INFO   | jvm 1| 2007/10/10 13:47:41 | 2007-10-10 13:47:41,036 
[SocketListener0-4] ERROR 
org.apache.maven.archiva.repository.scanner.RepositoryContentConsumers:default  
- Consumer [repository-purge] had an error when processi
ng file 
[/Applications/Archiva/archiva/data/repositories/snapshots/org/codehaus/plexus/plexus-expression-evaluator/1.0-alpha-2-SNAPSHOT/plexus-expression-evaluator-1.0-alpha-2-20070928.003615-2.jar]: 
For input string: "alph"
INFO   | jvm 1| 2007/10/10 13:47:41 | 
java.lang.NumberFormatException: For input string: "alph"
INFO   | jvm 1| 2007/10/10 13:47:41 |   at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) 

INFO   | jvm 1| 2007/10/10 13:47:41 |   at 
java.lang.Integer.parseInt(Integer.java:447)
INFO   | jvm 1| 2007/10/10 13:47:41 |   at 
java.lang.Integer.parseInt(Integer.java:497)


This was the problem - can you offer any further what functionality 
actually changed and why I might have seen this problem?


I can't duplicate this.
I suspect that this was corrected with the swingover to 
RepositoryContent code too.

Can you get me a complete stack trace?





 
   1
-  
-
+  
+
   internal
   Archiva Managed Internal Repository
-  file://${appserver.base}/repositories/internal
+  ${appserver.base}/repositories/internal


These changes are incorrect, if it is version '1', it is the old 
format, you can't update the content (I'm surprised it works).


As far as I know, version 1 equals  + 
 etc...

This was required to allow the unit tests to operate.
Versions before 1 are in the realm of Archiva 0.9
And I don't see support for a version 2 in the code.


No, this isn't correct:

version null is 0.9.
version 1 was what you introduced, ie 
version 2 is what I changed it to  + 



There is no explicit handling of the version - the existence of 
 triggers the handling in the current case. Now that 
version is consistently set it should be easier to keep track of.


So, this change is likely to be problematic. We're going to need to 
roll back these changes and investigate why the tests actually broke.


I will do this.


This is likely related to MRM-546 (Duplicate repositories show up while 
editing).









On 10/10/2007, at 11:47 AM, [EMAIL PROTECTED] wrote:

-assertFalse( el.getValue().equals( "20070315032817" ) );
+// FIXME: assertFalse( el.getValue().equals( 
"20070315032817" ) );


what happened here? (2 more instances in the file)


That was a holdover on MRM-535, it was known to be bad.
I should have labelled that as // FIXME [MRM-535] instead.


but MRM-535 is fixed, why are they still commented out?


Not commented out in my code.
At least, I'm not seeing what you are seeing.
What File / line number are you referring to?







On 10/10/2007, at 11:47 AM, [EMAIL PROTECTED] wrote:

+/* FIXME
 public void 
testLegacyRequestPluginConvertedToDefaultPathInManagedRepo()

 throws Exception
 {
@@ -400,7 +401,7 @@
 setupTestableManagedRepository( path );

 File expectedFile = new File( managedDefaultDir, path );
-ArtifactReference artifact = createArtifactReference( 
"legacy", legacyPath );
+ArtifactReference artifact = 
man

Re: svn commit: r584994 - /maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java

[Joakim Erdfelt]

I got lazy, the tests in repository purge test for this already.
Lemme see what I can whip up in a more module local test case.

Brett Porter wrote:

looks good, but should there be a test case?

On 16/10/2007, at 9:31 AM, [EMAIL PROTECTED] wrote:


Author: joakime
Date: Mon Oct 15 18:31:40 2007
New Revision: 584994

URL: http://svn.apache.org/viewvc?rev=584994&view=rev
Log:
[MRM-535] metadata-updater is changing lastUpdating timestamp when it 
shouldn't
Correcting logic in snapshot metadata to only update on the following 
conditions.

* Last Updated exist in original metadata.xml or ...
* Last Updated timestamp as found in unique (timestamped) snapshots 
is newer.



Modified:

maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java 



Modified: 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java 

URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java?rev=584994&r1=584993&r2=584994&view=diff 

== 

--- 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java 
(original)
+++ 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/metadata/MetadataTools.java 
Mon Oct 15 18:31:40 2007

@@ -501,6 +501,22 @@

 return cal.getTime();
 }
+
+private long toLastUpdatedLong( String timestampString )
+{
+try
+{
+Date date = lastUpdatedFormat.parse( timestampString );
+Calendar cal = Calendar.getInstance( 
DateUtils.UTC_TIME_ZONE );

+cal.setTime( date );
+
+return cal.getTimeInMillis();
+}
+catch ( ParseException e )
+{
+return 0;
+}
+}

 private long getLastUpdated( ArchivaRepositoryMetadata metadata )
 {
@@ -570,16 +586,12 @@
 {
 File metadataFile = new File( 
managedRepository.getRepoRoot(), toPath( reference ) );


-long originalLastUpdated = getExistingLastUpdated( 
metadataFile );

+long lastUpdated = getExistingLastUpdated( metadataFile );

 ArchivaRepositoryMetadata metadata = new 
ArchivaRepositoryMetadata();

 metadata.setGroupId( reference.getGroupId() );
 metadata.setArtifactId( reference.getArtifactId() );
-if ( originalLastUpdated > 0 )
-{
-metadata.setLastUpdatedTimestamp( toLastUpdatedDate( 
originalLastUpdated ) );

-}
-
+
 if ( VersionUtil.isSnapshot( reference.getVersion() ) )
 {
 // Do SNAPSHOT handling.
@@ -619,7 +631,11 @@
 {
 String tsDate = mtimestamp.group( 1 );
 String tsTime = mtimestamp.group( 2 );
-metadata.setLastUpdated( tsDate + tsTime );
+
+long snapshotLastUpdated = 
toLastUpdatedLong( tsDate + tsTime );

+
+lastUpdated = Math.max( lastUpdated, 
snapshotLastUpdated );

+
 metadata.getSnapshotVersion().setTimestamp( 
m.group( 2 ) );

 }
 }
@@ -631,9 +647,12 @@

 metadata.setSnapshotVersion( new SnapshotVersion() );

-/* TODO: Should this be the last updated timestamp 
of the file, or in the case of an

+/* Disabled due to decision in [MRM-535].
+ * Do not set metadata.lastUpdated to 
file.lastModified.

+ *
+ * Should this be the last updated timestamp of the 
file, or in the case of an

  * archive, the most recent timestamp in the archive?
- */
+ *
 ArtifactReference artifact = getFirstArtifact( 
managedRepository, reference );


 if ( artifact == null )
@@ -648,6 +667,7 @@
 Date lastModified = new Date( 
artifactFile.lastModified() );

 metadata.setLastUpdatedTimestamp( lastModified );
 }
+*/
 }
 else
 {
@@ -659,6 +679,12 @@
 {
 // Do RELEASE handling.
 metadata.setVersion( reference.getVersion() );
+}
+
+// Set last updated
+if ( lastUpdated > 0 )
+{
+metadata.setLastUpdatedTimestamp( toLastUpdatedDate( 
lastUpdated ) );

 }

 // Save the metadata model to disk.



--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: svn commit: r585583 - in /maven/archiva/trunk/archiva-reporting/archiva-artifact-reports/src/main/java/org/apache/maven/archiva/reporting/artifact: DuplicateArtifactsConsumer.java LocationArtifact

[Joakim Erdfelt]

Good catch.
That is minor problem, and contained entirely within the reporting 
consumers with this change.

I'll fix that toot-sweet.

- Joakim

Brett Porter wrote:


On 18/10/2007, at 3:23 AM, [EMAIL PROTECTED] wrote:


@@ -294,13 +294,14 @@
 {
 try
 {
-BidirectionalRepositoryLayout layout = 
layoutFactory.getLayout( artifact );

-return layout.toPath( artifact );
+String repoId = artifact.getModel().getRepositoryId();
+ManagedRepositoryContent repo = 
repositoryFactory.getManagedRepositoryContent( repoId );

+return repo.toPath( artifact );
 }
-catch ( LayoutException e )
+catch ( RepositoryException e )
 {
 getLogger().warn( "Unable to calculate path for 
artifact: " + artifact );

-return null;
+return "";
 }


Is that really an appropriate response to a request for a path, or 
will this expect the caller to do some error handling on the empty 
string?


Also - the commit seems to be spread out across multiple revisions 
again - what tooling are you using?


- Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: Archiva Consumers question

[Joakim Erdfelt]

Brett Porter wrote:

Well, since you asked :)

On 17/10/2007, at 2:10 PM, Joakim Erdfelt wrote:


ArchivaArtifactConsumer is an abstract-dealing-with-artifacts consumer.
RepositoryContentConsumer is for files.

A file that isn't an artifact can be *.xml, *.sha1, *.md5, 
maven-metadata.xml, bad content, poorly named content, etc.


Would it be better to state the phase/scan instead?

RepositoryContentConsumer becomes -> RepositoryScanConsumer
ArchivaArtifactConsumer becomes -> DatabaseScanConsumer


These seem better, though there is still some question over even these 
names. I suggest following through on Wendy's questions before jumping 
ahead with anything.




And I would rather make this change now (yes Brett, I see you there) 
and not have to deal with backwards compatibility issues post 1.0 "in 
the wild".  This time (right now) is the best time to make this 
change.  After the 1.0 release is just going to add misery and pain 
to this process.  Now is the sweet spot.  We could make the change 
post 1.0 but it wouldn't be a change, it would just be another 
band-aide.   Make the change now.   Did you know that making the 
change now would take less than an hour, including testing.  I think 
that Now is a good time.  Now is the winter of our discontent.  Right 
now, hey, its your tomorrow.  Right now, C'mon (Brett), its 
everything.  Right now, catch a magic moment, do it, right here and 
now.  It means everything.  Its right now, oh, tell me what are you 
waiting for, turn this thing around. :-)


I know you're somewhat kidding here, but I'm not quite sure how much, 
so I'll say it anyway :)


I am not kidding, make this change now.
I'll do it. It's no big deal.



I do not agree that 1.0 is some miracle milestone of inflexibility.

For two reasons:
a) whatever in the wild milestone you are referring to should have 
been at the point of beta-1, as I said in the last mail

b) it's bad thinking that things can't change after 1.0


That sounds reasonable, and a statement not based on fear of change, but ...



Frankly, I would prefer that development was done in the same fashion 
whether it's 0.0.1-alpha-0, 1.0, 1.0.1, 1.1, 2.0 or Archiva 2008. 
Simple, minimal public API exposure that allows maintaining 
compatibility and the ability to refactor implementation details 
within a module.


This statement contradicts your previous one.
What we now want to change now is a public API.
I do not want to fall into the same trap that maven fell into when it 
comes to "maintaining compatibility", we have far too much in maven that 
exists solely for "maintaining compatibility" that is complete and utter 
cruft.


We are in that situation because of 2 major factors.
1) A hurry up and get a release out mindset.
2) A fear of changing the new APIs before a final (non-beta, non-RC, 
release)


Now is the perfect time to correct this.
Lets do it now.
Lets put it up for a vote now.



Let's just define what the acceptable extension points for Archiva 1.0 
are (probably consumers, so maybe you've found the one example where 
it might be difficult!), document them, and commit to maintaining them 
and move forward in that way.


- Brett


--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: Archiva Consumers question

[Joakim Erdfelt]

Everything in the UI uses the database.
A full scan from disk to database take *FAR* too long.

This was setup as a tiered effort. 
First step. get the real, valid, useful content off of disk and into the 
database into a usable form.

Second step. expand the data in the database fully.

The first step makes the content available for browse immediately, in 
the order of ~55ms per file.

The second step takes an average of 3 seconds per file right now.
NOTE: Even though the database scan is short now, this is expected to 
take multi-minute per artifact in the future, as the consumer complexity 
start to grow. (think bytecode scan / checksumming / indexing / 
cross-referencing, and gpg signature confirmation processes to name just 
2 that we are aware of)


In large repositories, this is the only way to get the content available 
within a 24 hour window.
This problem also exists with the old technique + large repositories + 
scan for new content.


- Joakim

Wendy Smoak wrote:

On 10/16/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
  

ArchivaArtifactConsumer is an abstract-dealing-with-artifacts consumer.
RepositoryContentConsumer is for files.

A file that isn't an artifact can be *.xml, *.sha1, *.md5,
maven-metadata.xml, bad content, poorly named content, etc.

Would it be better to state the phase/scan instead?

RepositoryContentConsumer becomes -> RepositoryScanConsumer
ArchivaArtifactConsumer becomes -> DatabaseScanConsumer



All artifacts _are_ repository content, are they not?  And even after
the renaming... it can't be in the database unless it's in the
repository.

I understand scanning the filesystem to update the database.  But when
and why do you "scan" the database?

  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: critical issue with 1.0-beta-2 !!!

[Joakim Erdfelt]

There are 4 split points present in every filename.
ArtifactId|version|classifier|type

Determining the artifactId and version is easy enough with maven 2 
default layout, as the artifactId and version are present in the full 
path to the artifact.


example:
http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar

But working with maven 1 requests, this is *much* more ambiguous and non 
deterministic.


Some file / layout problems found in Jira.

MRM-519 [Fail to resolve artifactId for libs that contain versionKeyword 
in artifactId, like "maven-test-plugin"]
This comes from the fact that you are likely requesting the 
maven-test-plugin from using a maven 1 (legacy) layout format from a 
repository on archiva that is configured as maven 2 (default) layout 
storage.

This translation cannot work 100% of the time.

MRM-432 [Proxy Connectors are unable to download artifacts with alpha 
numerical version numbers]
This one is about oddball version ids such as found in 
ganymed-ssh-build210.jar, comm-3.0-u1.jar, and 
ejb-3.0-public_review.jar.  These version specs are difficult to 
identify as part of the version, and not the classifier.


MRM-517 [Some maven 2 requests are treated as maven 1 requests]
This is due to the duality of request handling in the present 
/repository/ URL.


Some Ideas:

One idea I had last night was to rework the filename to artifact object 
for Legacy layout to be a list of potential Artifact object's, but this 
is really only relevant when working with the translation between an 
incoming request at maven 1 (legacy) to a maven 2 (default) resource. 
(this flow applies for internal repository translation, and also 
proxying of content from remote repos at different layout formats)


Another idea is to split the /repository/ url into two, using the 
/repository/legacy/ or /repository/default/ identifiers to clearly 
identify what your intention is.  Use this along with pom information on 
the same file (when a legacy request occurs) should clear up any confusion.


- Joakim


nicolas de loof wrote:

As Joakim noticed, my quick-fix patch breaks many testcases. It also
doesn't covers some valid cases, like the use of classifiers with "-"
tokens.

Still looking for a working artifactId detection strategy...

I myself sometime hardly discover the artifactId. Lets look at groovy :
"groovy-1.0-jsr-06"

Is this "groovy" artifact with version "1.0-jsr-06",
or (as it is in repo) "groovy-1.0-jsr" version "06" ?
I'm not sure there is any fully deterministic way to solve this.

Maybe the only way to solve this is to have RepositoryLayoutUtils
manage an "exception" list to it's default token based discovery. And
this would require some more UI to configure it...

Nico.

2007/9/25, nicolas de loof <[EMAIL PROTECTED]>:
  

I've created http://jira.codehaus.org/browse/MRM-519 for this and
attached a patch.

2007/9/25, nicolas de loof <[EMAIL PROTECTED]>:


I just installed beta-2 in replacement to my corporate repo.
I may had better tested it before :-(

requesting using maven1 an artifact with "-" in artifactID fails :

request for "maven/plugins/maven-test-plugin-1.8.2.jar"
in logs :
\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
does not exist

The versionUtil.versionPatterns seems to grab too much tags as possible version.

I've patched it locally to remove "test[_.0-9]*" as possible version
pattern. Could we enhance this artifactId detection by ensuring ALL
tokens considered as version are valid versionElements ?

Something like this :
[- ]+ [- ]+ [- ]?

In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
valid versionElement, "test" and "plugin" may have been added to the
artifactId

  


  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: Documentation Plan

[Joakim Erdfelt]

The order is a little odd.
I would personally put the User's Guide as more important than the 
Developer's Guides.

The FAQ should be higher in the list too.

- Joakim


Emmanuel Venisse wrote:

Hi,

Here is the structure of the documentation I'd like to have for 
1.1-final.



Installation/Upgrade Guides
Installation (standalone, webapp, service...)
Release Notes
Upgrade
Administrator's Guides
Managing Users and Security
Adding Project Group
Managing Builders
Managing JDKs
Managing Profiles
Managing Schedules
Managing General Configuration (configuration and appearance)
Developer's Guides
SVN repository structure
XML-RPC
TO BE DEFINED
User's Guides
Managing a project
Add (maven1, maven2, Ant, Shell), Remove, Edit
SCM security hints
Managing Build Definitions
Managing Notification
mail to an address, mail to latest committers, irc, 
jabber, msn, wagon, alwaysSend...

Building a project
Release Management
Knowledge Base
FAQ (sorted by categories, maybe one menu entry by category)
Old versions
1.0.x site


About videos, I don't know yet where to put them. Maybe a video 
attached to a page (like Add Maven2 project) instead of a specific 
videos page in the menu.


WDYT?

Emmanuel




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

[PROPOSAL] Dropping archiva-cli and archiva-converter

[Joakim Erdfelt]

I'd like to drop (or move to the archiva-sandbox) the archiva-cli and 
archiva-converter modules.


Does anyone see any reason to keep these two modules around anymore?

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: Using HTTP repositories for consumption only

[Joakim Erdfelt]

Just a thought, but why not dump wagon in 2.1 and just use the java.net
package for file / http / https / ftp fetch, any valid java.net.URL
could work that way.

Instead of picking and choosing what to support, just punt and support
what is in java itself for fetch.

And we can get rid of a lot of commons-* stuff in the core binary too.

- Joakim

John Casey wrote:
> I think it's also a reasonable goal to allow people to use projects
> that refer to embedded remote repositories to build...that way, the
> build is totally self-contained. This is one of the things that the
> assembly plugin tries to do with its  section (though
> it doesn't work very well so far...but that's just a matter of time).
>
> IMO, file:// is a nice thing to have, unless we have some way of
> allowing the above to work without the file wagon being in core (maybe
> I'm not thinking about it the right way).
>
> -john
>
>
> On Sep 7, 2007, at 8:20 PM, Brian E. Fox wrote:
>
>> I don't currently, but have in the past used file:// for remote.
>>
>> The use case was that we had to mirror our internal repo to another corp
>> network. We essentially zipped up the repo and transferred it to their
>> machine (regularly and automatically via scm), which set a mirror entry
>> pointing to the local fs. This had to be done this way because a proxied
>> connection to our internal repo was not allowed, they needed full copies
>> of the entire build in scm.
>>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Olivier Lamy as Continuum committer

[Joakim Erdfelt]

+1

/(Whoa, this is some serious deja-vu for me.)/

- Joakim

Emmanuel Venisse wrote:

Hi,

I'd like to give to Olivier commit access to Continuum.
He provided lot of good patches, implemented new features 
(installations/profiles) and help users on the mailing lists


here, my +1

Emmanuel




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Archiva-1.0-beta-1

[Joakim Erdfelt]

I closed it because the points raised were in areas / objects / classes 
that I felt no longer existed in the current codebase. 


I COULD BE WRONG!  (quite likely actually)

Feel free to reopen any ticket you feel needs more attention.
Don't be afraid to reopen tickets, especially with an explanation, I 
personally consider that to be a normal operation of a issue tracking 
system.   I won't get offended by it, honest! :-)


- Joakim

nicolas de loof wrote:

Why is this no longer valid ?
When I ask for a snapshot that is allready present in the managed repo, the
proxied repository are not fetched as the "hasRessource" return true...

I'll prepare a testCase for snapshots updates and attach it to jira, so it
can be better tested.

2007/8/7, Joakim Erdfelt <[EMAIL PROTECTED]>:
  

I'm the one that closed that jira.
I only closed it as won't fix because there wasn't an option "no longer
valid". ;-)

The CacheFailurePolicy catch was good, thanks! it'll be fixed in svn
shortly.
If I could trouble you to report any snapshot bugs you find into jira
(that would be wonderful) as snapshot functionality is important, but
poorly tested.

- Joakim

nicolas de loof wrote:


The snapshot issue is reported in MRM-320 that has been closed as "won't
fix".
Doesn't archiva support snapshots updates ;-p ?

2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:

  

Without those configuration issues, you get my +1 for a beta.

the "repository/*" url works fine for both maven1 and maven2 requests.
The only feature I'm still missing is having archiva


internally  handling


relocation for artifacts requested by maven1... maybe in beta-3 ?

I also notice the ProxiedDavServer "get" method still use hasResource()
and bypass fetching from propxies if present, so there's no way to get


newer


snapshots. This may change with the separation between webdav and "GET"
urls.

Nico.



2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:



MRM-460 created.
The typo is only in CacheFailurePolicy log message.
The main issue is about the archiva default config that refers to an
invalid "cache" value.


Abnother issue with the proposed beta : I had to edit wrapper.conf to
set
   wrapper.java.initmemory=8
as I got (on windows, using run.bat) :
jvm 1| [ERROR] Specified initial heap size (3 MB) is less than the
minimum required initial heap size (8 MB).
jvm 1| Could not create the Java virtual machine.


2007/8/7, Brett Porter <[EMAIL PROTECTED]>:

  

Is this actually the checksum policy checker, or is it a typo in the
description too?

Can you put this as a patch in jira? :)

- Brett

On 07/08/2007, at 6:55 PM, nicolas de loof wrote:




It seems to be a typo in CachedFailuresPolicy

"
public boolean applyPolicy( String policySetting, Properties
request,
File localFile )
{
if ( !options.contains( policySetting ) )
{
// No valid code? false it is then.
getLogger().error( "Unknown checksum policyCode [" +
policySetting + "]" );
return false;
}
"

That beeing said, the constant is set to "cached" and the default
config to
"cache".
Editing the network-proxies and setting to "cached" solved this.


2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:

  

I cannot get any artifact from proxy due to some strange checksum
policy
error :

According to log, the proxied-repo is set to policy[checksum]:fix :
ProxyConnector[
jvm 1|
source:ArchivaRepository[internal,file://D:\temp\.data/
repositories/internal]
jvm 1|   target:ArchivaRepository[central,
http://repo1.maven.org/maven2]
jvm 1|   proxyId:
jvm 1|   policy[releases]:once
jvm 1|   policy[checksum]:fix
jvm 1|   policy[snapshots]:disabled
jvm 1|   policy[cache-failures]:cache
jvm 1| ]

But latter, I get an Error about Unknown checksum policyCode



[cache]



jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures


  -


Unknown checksum policyCode


I also had to delete my old $HOME/.m2/archiva.xml as I cannot make
any
change in the configuration "cannot save configuration when 2
sources are
used".
Is there any update guide to convert old-style configuration into
archiva
1.0 ? If none, why does archiva still read this deprecated and
uneditable
archiva.xml file ?

Nico.

Re: [VOTE] Release Archiva-1.0-beta-1

[Joakim Erdfelt]

I'm the one that closed that jira.
I only closed it as won't fix because there wasn't an option "no longer 
valid". ;-)


The CacheFailurePolicy catch was good, thanks! it'll be fixed in svn 
shortly.
If I could trouble you to report any snapshot bugs you find into jira 
(that would be wonderful) as snapshot functionality is important, but 
poorly tested.


- Joakim

nicolas de loof wrote:

The snapshot issue is reported in MRM-320 that has been closed as "won't
fix".
Doesn't archiva support snapshots updates ;-p ?

2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
  

Without those configuration issues, you get my +1 for a beta.

the "repository/*" url works fine for both maven1 and maven2 requests.
The only feature I'm still missing is having archiva internally  handling
relocation for artifacts requested by maven1... maybe in beta-3 ?

I also notice the ProxiedDavServer "get" method still use hasResource()
and bypass fetching from propxies if present, so there's no way to get newer
snapshots. This may change with the separation between webdav and "GET"
urls.

Nico.



2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:


MRM-460 created.
The typo is only in CacheFailurePolicy log message.
The main issue is about the archiva default config that refers to an
invalid "cache" value.


Abnother issue with the proposed beta : I had to edit wrapper.conf to
set
   wrapper.java.initmemory=8
as I got (on windows, using run.bat) :
jvm 1| [ERROR] Specified initial heap size (3 MB) is less than the
minimum required initial heap size (8 MB).
jvm 1| Could not create the Java virtual machine.


2007/8/7, Brett Porter <[EMAIL PROTECTED]>:
  

Is this actually the checksum policy checker, or is it a typo in the
description too?

Can you put this as a patch in jira? :)

- Brett

On 07/08/2007, at 6:55 PM, nicolas de loof wrote:



It seems to be a typo in CachedFailuresPolicy

"
public boolean applyPolicy( String policySetting, Properties
request,
File localFile )
{
if ( !options.contains( policySetting ) )
{
// No valid code? false it is then.
getLogger().error( "Unknown checksum policyCode [" +
policySetting + "]" );
return false;
}
"

That beeing said, the constant is set to "cached" and the default
config to
"cache".
Editing the network-proxies and setting to "cached" solved this.


2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
  

I cannot get any artifact from proxy due to some strange checksum
policy
error :

According to log, the proxied-repo is set to policy[checksum]:fix :
ProxyConnector[
jvm 1|
source:ArchivaRepository[internal,file://D:\temp\.data/
repositories/internal]
jvm 1|   target:ArchivaRepository[central,
http://repo1.maven.org/maven2]
jvm 1|   proxyId:
jvm 1|   policy[releases]:once
jvm 1|   policy[checksum]:fix
jvm 1|   policy[snapshots]:disabled
jvm 1|   policy[cache-failures]:cache
jvm 1| ]

But latter, I get an Error about Unknown checksum policyCode


[cache]


jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures  -
Unknown checksum policyCode


I also had to delete my old $HOME/.m2/archiva.xml as I cannot make
any
change in the configuration "cannot save configuration when 2
sources are
used".
Is there any update guide to convert old-style configuration into
archiva
1.0 ? If none, why does archiva still read this deprecated and
uneditable
archiva.xml file ?

Nico.


  


  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: reporting & jasper reports

[Joakim Erdfelt]

Brett Porter wrote:

On 03/08/2007, at 3:23 AM, Joakim Erdfelt wrote:
And with the dozen or so licenses in use by ant and maven, how and 
why is this suddenly important to archiva, but not the other projects?


In maven and ant we have jgpl'd and oddball licenses such as ...
checkstyle, clover, netrexx, jruby, judo, jython, javamail, 
activation, and jai.


The key point is distribution. Ant does not distribute any of these. 
Maven is in a grey area, where it downloads them (so is compliant), 
but does so automatically (which makes it a few shades of grey given 
it's a policy aimed at "no surprises" licensing). There's no doubt it 
can be improved. Also a factor is that a lot of these predate the 
policy, and the policy has a transition period which is what I linked to.


But Archiva is doing this for the first time, in awareness of the 
policy, and as it stands would have to distribute the JAR - so I think 
we need to take it into consideration. Discussions about the policy 
itself belong on legal-discuss - we should just deal with the best way 
to apply it.


So far others have agreed with the approach outlined using a profile - 
do you have any other issues with doing that?


That translation (explanation?) is *far* easier to understand than the 
URL you pointed to.


Teody said on this thread yesterday that he was working on updates 
based on the feedback Deng had given in the issue, so if that patch 
looks ok too and gets applied, we'll then need to deal with this 
before we can move forward with the release next week.


The current set of patches are already applied.
We'll have to kinda/sorta undo them.

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: reporting & jasper reports

[Joakim Erdfelt]

Brett Porter wrote:

Hi all,

This is mainly for Deng and Teody as I've seen them working through 
the issue for reporting... I took a look at the latest patch and it's 
looking pretty good.


I did go to check about the jasper reports license, though, and it 
appears from the POM that it is LGPL.


Though it's not official (yet), we shouldn't be distributing it 
according to the ASF policy: 
http://people.apache.org/~cliffs/3party.html#transition


So, I think we have 3 options if we continue to do this:
- put it in a separate module (and profile) that isn't distributed 
with continuum, but can be built manually and installed
- require the user to drop jasperreports into WEB-INF/lib (and 
gracefully fail if they don't)
- come up with a whiz-bang addon installer that can get them to 
confirm the license and grab the jasper stuff from the repository (a 
bit much for now :)


I'm thinking 1) is the best way to go, and provide a bland, default 
implementation of the reporting pages that doesn't use jasper (just a 
spit out a table of everything).


WDYT?


While I understand the need to be vigilant on licenses in use.
I don't understand why LGPL is excluded.

And that URL you pointed to seems to makes a distinction only on using 
LGPLed code.


And with the dozen or so licenses in use by ant and maven, how and why 
is this suddenly important to archiva, but not the other projects?


In maven and ant we have jgpl'd and oddball licenses such as ...
checkstyle, clover, netrexx, jruby, judo, jython, javamail, activation, 
and jai.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: Archiva releases (Take 2)

[Joakim Erdfelt]

For the record.

Archiva runs fine on jetty 5.x and 6.x.

- Joakim

Ludovic Maitre wrote:

Hi Maria, all,

Although i'm a new user of Archiva, i would like to know when in the 
roadmap the team plan to fix issues related to running Archiva inside 
Tomcat (issues like http://jira.codehaus.org/browse/MRM-323 ) ? Is it 
something important for the team ? Did you expect users to deploy 
Archiva standalone in production ?

Best regards,

Maria Odea Ching wrote:

Hi All,

We (Brett, Joakim and I) have segregated the issues in Jira to prep 
for the upcoming 1.0 release (finally! :-) ). Anyway, there'll be two 
beta releases first before 1.0.


So..here's the plan (excerpted from Brett):
- finish all issues for 1.0-beta-1
- then move on to 1.0-beta-2 issues for the next release
- do a big bug bash to find the problems in it
- decide on these found bugs for 1.0-beta-3 or 1.0.x (known issues)


Btw, I'll prepare 1.0-beta-1 for release on August 6 (that'll be 
Monday my time), and this will include the following:

1. Resolved/Closed:
- MRM-290 (Ability to pre-configure the Jetty port in conf/plexus.xml)
- MRM-326 (Adding/Editing repositories doesn't have validation)
- MRM-425 (Search and Browse do not work for snapshots)
- MRM-426 (Search does not work for snapshots because of different 
version values in index and database when the snapshot version is 
unique)


2. In Progress/Open:
- MRM-143 (Improve error reporting on corrupt jars, poms, etc)
- MRM-275 (add "remove old snapshots" Scheduler)
- MRM-294 (Repository purge feature for snapshots)
- MRM-329 (The Reports link gives an HTTP 500)
- MRM-347 (Undefined ${appserver.home} and ${appserver.base})
- MRM-373 (Unable to delete the pre-configured example network proxy)
- MRM-412 (Add support for maven 1 (legacy) request to access a 
maven2 (default layout) repo )
- MRM-428 (Managed and remote repositories with same name causes 
problems)

- MRM-429 (Find artifact does not work when the applet is disabled)
- MRM-430 (Archiva always writes to ~/.m2/archiva.xml)

Everyone okay with this? :)


Thanks,
Deng














--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: What is Archiva.NEXT ?

[Joakim Erdfelt]

Both of those choices do not provide the ability for the client to 
identify itself.

Maven doesn't do it.
Wagon doesn't do it.
Ivy doesn't do it.

So we are left with having some identification of the client via the URL.

The long term future direction of Archiva is to support as many clients 
as possible.

It is myopic to assume that everyone is going to use Maven 2.

Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy (all 
Apache projects).


Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we have 
problems supporting Maven 1.0 with the auto-discovery approach.


I'm sure we have unit tests for auto-discovering the type of request.
Currently needs to support

* Artifact for layout of type default.
* Metadata for type default.
* Checksum request for type default.
* Artifact for layout of type legacy.
* Metadata for type legacy.
* Checksum request for type legacy.

- Joakim

nicolas de loof wrote:

I'd suggest to keep the existing "/repository//path" as get URL, so
that existing archiva user (as I am) that have configured maven clients to
point to this URL don't have to make changes on developpers PCs when
upgrading...

Having a distinct webdav URL "/webdav///path" is OK as this is set
in the POM for projects that use it for deployment, so required changes are
limited.

That beeing said, I don't understand the "technical reasons to not do"
auto-discovery of repository path based on the requested resource, when
possible. I understand there may be some conflicts, and that a determinist
URL has to be supported to avoid them (/repository//maven/
for maven1, /repository//maven2/ for maven2, ...).
But this doesn't exclude to also have an auto-discovery based on
"/repository//" that ask any registered layout for support on
the requested . If multiple are found, request may be rejected. The
idea here is to allow support for maven1/maven2 request on the same get URL
root, as supported by archiva-0.9.

To avoid any URL conflict, we could :

- use /webdav// as webdav URL
- use /get/// as deterministic get URL
- use /repository// as auto-discovery, for backward
compatibility with archiva-0.9

Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
  

Joakim,

Did we ever reach agreement on the format of these URLs? It'd be
great to get it nailed down before beta-1 rolls out :)

Cheers,
Brett

On 04/07/2007, at 11:28 AM, Brett Porter wrote:



So, last time this topic came up, there was disagreement on the /
get/ interface.

Regarding using /get/ instead of just /repository/ URL as is, I
said (<[EMAIL PROTECTED]>)...
"Ok, while I'd definitely prefer to make it work, if it can't then
I'd prefer we made the change in the other direction (the default
repository URL is get only, we have /repository-id/webdav/ as the
webdav exposure point)."
to which Nicolas agreed.

We then diverged into discussing auto-discovery of the getId from
the path which there were technical reasons to not do.

However, I do not want all repositories to look like /archiva/
repository/releases/get/maven2/. Yikes.

Cheers,
Brett

On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:

  

Design.

1) Create DynamicGetServlet which parses 
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves
artifacts / poms / metadata to it.
4) Test
5) Done.

- Joakim

Re: [VOTE] Graduate maven-patch-plugin from sandbox and release version 1.0

[Joakim Erdfelt]

+1

- Joakim

John Casey wrote:

Hi all,

Jesse and I have been working on a patch plugin that I migrated over 
from mojo.codehaus.org into the ASF sandbox, and we feel it's ready 
for a release. I've prepared the documentation for a code grant on 
this project, and all the appropriate information should be committed 
in the plugin directory.


The plugin is stable, has decent documentation, and even an 
integration-test suite. Therefore, I'd like to call a vote to graduate 
the patch plugin from the Maven sandbox, and do a 1.0 release.


Please +1/+0/-1. I'll let this go for 72 hours.

The release is staged at:

http://people.apache.org/~jdcasey/stage/repo (repository)
http://people.apahce.org/~jdcasey/stage/sites/maven-patch-plugin (site)

Here's my +1.

Thanks to Jesse for helping me get the plugin to this point.

-john


---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john






--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Shared JAR component 1.0

[Joakim Erdfelt]

+1

Brett Porter wrote:
This component is used in the project-info-reports plugin (and is a 
prereq to its next release) and analyses JAR files for Maven 
information and general Java class information.


Tag: 
https://svn.apache.org/repos/asf/maven/shared/tags/maven-shared-jar-1.0

Staging Repo: http://people.apache.org/~brett/stage-repo/
Website/documentation: http://maven.apache.org/shared/maven-shared-jar/

[ ] +1
[ ] 0
[ ] -1

72 hours go!

Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is Archiva.NEXT ?

[Joakim Erdfelt]

Design.

1) Create DynamicGetServlet which parses 
/get/${getId}/${getResource}
2) Create Maven1GetProvider which has an id "maven1", and serves 
artifacts / poms to it.
3) Create Maven2GetProvider which has an id "maven2", and serves 
artifacts / poms / metadata to it.

4) Test
5) Done.

- Joakim

Brett Porter wrote:
Sounds good. With the M1 client support, can you post a small design 
proposal first since last I remember we didn't reach consensus on how 
it should be implemented?


- Brett

On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:


I agree.

I view 1.0-beta-1 as feature complete.

The current missing features ...
* Reporting (about 80% there right now, just some UI pieces left to 
hook up)
* Maven 1 Client Support (about 40% complete. need to hook up 
DynamicGetServlet)

* Live documentation. (present in archiva.war)

- Joakim

Brett Porter wrote:


On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:


Archiva 1.0-alpha-2 is out in the wild... what's next?  1.0-beta-1
seems reasonable, but /topic in #archiva says "coming soon, the
Archiva 1.0 (the "Ship It" release)".


I was kidding (but that should be the focus from now on. Get it 
done.) I agree 1.0-beta-1 is next - it should be feature complete.



- Brett





--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer





--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: What is Archiva.NEXT ?

[Joakim Erdfelt]

Wendy Smoak wrote:

On 7/2/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:


* Live documentation. (present in archiva.war)


Can you explain what you want to do here?  Does it work off the
existing apt source and get bundled into the .war file, or something
else?

Live documentation.
Shipped in the archiva.war, and linked in the UI.
I wanted to see a set of documentation for setting up your maven1 and 
maven2 projects to utilize the repositories, complete with valid 
copy/paste sections, etc...


We also need better descriptions on the UI elements in the admin screens.
I created http://jira.codehaus.org/browse/MRM-366 to address that.

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Released 1.0 Binaries

[Joakim Erdfelt]

I think we should strive to release more binary options for archiva in 
the next set of releases.


apache-archiva-${version}-bin.tar.gz
apache-archiva-${version}-bin.tar.bz2
apache-archiva-${version}-bin.zip
apache-archiva-${version}.war

As I write this I am left with the question ...
Should it be "standalone" instead of "bin"?

We should also generate the different source tarball versions too.

apache-archiva-${version}-src.tar.gz
apache-archiva-${version}-src.tar.bz2
apache-archiva-${version}-src.zip

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer

Re: svn commit: r549064 - /maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java

[Joakim Erdfelt]

Jason van Zyl wrote:


On 20 Jun 07, at 10:13 AM 20 Jun 07, Joakim Erdfelt wrote:


Be sure that this doesn't break forward compatibility too.

That approach would not allow for proper mirroring, authentication 
propagation, network proxy usage, and short-circuits the whole wagon 
manager approach of wagon 2.x




Why is there any concept of mirroring in Wagon.

You are basically deciding all this stuff on your own and making 
changes based on what you need in Archiva.

That's nice.
But there's no mirroring in Archiva.  Nor is there any need for it.
Archiva actually uses wagon 1.x, not wagon 2.x or the wagon-manager.
There's pretty much zero discussion surrounding all the changes you 
are making and if you expect that to be absorbed into Maven you're 
going to have a hard sell after what happened the last time it was 
attempted. If the APIs are not compatible while the code is improved I 
will be -1 on its inclusion in any version of Maven. There is no 
reason the changes cannot be more gradual, and made to work with 1.x, 
2.0.x, 2.1.x.

Zero?  Hardly.

The discussion for those changes were made in irc a full 5+ months ago.
Regrettably it was not discussed in an archived format, like here in the 
mailing list.

We've all got this disease.  We all have to resolve to change this behavior.
I'm honestly not in favor of using something so divergent as it's 
being driven by the use of one application, we'll have a hard time 
getting it to work right in Maven and we're going to very much screw 
Maven 1.x because we're yet again going to change/fix everything on 
something completely different then what they using. This is 
especially important now that Maven 1.1 is imminent.

The decision was made to ...
a) Consolidate the myriad of usages for wagon into a single point.
b) Not duplicate code within maven client + wagon + plugins to 
accomplish the same task.
c) Give everyone a consistent interface, to get the full benefits of 
authentication + mirroring + network proxying (which currently is 
implemented differently with every usage of wagon)

d) Fix the numerous bugs present in wagon.

Direct usage of the wagon, not through the wagon manager, means a lot 
less functionality than desired.




This is what Wagon was made for which is why the WagonManager was 
always in Maven itself. The manager capability is nice, I agree, but 
is not of prime importance in Wagon. The prime important is a simple 
API for transport that works well for each of the providers. I fear 
the API is going to get out of control like many of our other APIs 
because the complexity of having this to work in something like 
Archiva is going to pull in another kitchen sink.

I never proposed eliminating the direct wagon impl usage / use case.
Just make everyone that decides to use it that way aware that they have 
*MORE* work ahead of themselves in order to be consistent with wagon 
usage everywhere else in maven client.


- Joakim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r549064 - /maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java

[Joakim Erdfelt]

Be sure that this doesn't break forward compatibility too.

That approach would not allow for proper mirroring, authentication 
propagation, network proxy usage, and short-circuits the whole wagon 
manager approach of wagon 2.x


Direct usage of the wagon, not through the wagon manager, means a lot 
less functionality than desired.


- Joakim

[EMAIL PROTECTED] wrote:

Author: kenney
Date: Wed Jun 20 04:06:27 2007
New Revision: 549064

URL: http://svn.apache.org/viewvc?view=rev&rev=549064
Log:
Restore backwards compatibility - fix the deprecated method.

Modified:

maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java

Modified: 
maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
URL: 
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java?view=diff&rev=549064&r1=549063&r2=549064
==
--- 
maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
 (original)
+++ 
maven/wagon/trunk/wagon-provider-api/src/main/java/org/apache/maven/wagon/AbstractWagon.java
 Wed Jun 20 04:06:27 2007
@@ -197,6 +197,9 @@
 public void connect( Repository repository, AuthenticationInfo 
authenticationInfo, ProxyInfo proxyInfo )
 throws ConnectionException, AuthenticationException
 {
+setRepository( repository );
+setAuthenticationInfo( authenticationInfo );
+setProxyInfo( proxyInfo );
 connect();
 }
 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  



--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Planning for 1.0-alpha-2

[Joakim Erdfelt]

There are a few proxy related bugs left to work out in 1.0-alpha-2, I'd 
like to get a functional proxying working for the 1.0-alpha-2 release.


I think this weekend might be doable.  But that depends on the help 
testing the bug fixes.


- Joakim

Wendy Smoak wrote:

How does the weekend of June 23rd sound for another Archiva alpha
release?  Joakim, are you already planning to do one before then?

Any thoughts on how many of the 110 issues marked for 1.0-alpha-2 in
jira could actually make it in that two-week time frame?

Thanks,
Wendy

Re: [VOTE] Release Maven 2.0.7 (take 2)

[Joakim Erdfelt]

+1

How can I not vote +1?  After all, according to the META-INF/MANIFEST.MF 
in the maven-core-2.0.7-uber.jar I built it.


Niggle: It still feels wrong to have the maven-core-2.0.7-uber.jar have 
a LICENSE.txt in it's root that says it's a GPL'd application.


- Joakim

Jason van Zyl wrote:

Hi,

The release notes are here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=13138 



The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/

Staging repository:

http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/maven-2.0.7/

Thanks,

Jason.



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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-dependency-tree changes for 1.1

[Joakim Erdfelt]

Mark Hobson wrote:

On 19/06/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

On 6/19/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
> Ah thanks, I wasn't aware of that - I had assumed archiva used
> dependency-tree, although I haven't got around to looking at archiva
> yet.  That certainly looks like the kind of code I was heading towards
> - I'll have a proper look and get back to you.  I'm just wondering how
> it could be more accurate than the resolution process that Maven core
> uses itself?

what would be the point of having a different resolution than the one
maven uses? If I see a dependency graph different of what maven uses
it would be really confusing


I agree, this is what I was trying to say.

I chose to ensure consistency with maven itself.
It is not nearly as confusing as it is now.

other than that let's just choose one of the libraries and deprecate
the other one to avoid splitting the work


archiva-dependency-graph appears to be quite tied in to archiva
itself, so I'm not sure how easy it'd be to move away from that.  The
situation so far appears to be:

- maven-dependency-tree uses the 2.0.x core APIs to build the same
tree as Maven actually uses
- archiva-dependency-graph is a good proof-of-concept of how
graph-based resolution could be implemented in 2.1, although is
currently quite tied to archiva itself

There are few decisions here in archiva.

1) The need to resolve project models differently.
   Archiva doesn't have a local repository, it has many managed repos.
   Archiva doesn't communicate with a remote repository unless directed 
to do so because of a client request.
   Archiva set up a ProjectModelResolver interface with a 
ProjectModelResolverStack to allow for control over the project 
resolution process.  Currently, archiva does resolution via the 
ProjectModelResolverStack, which specifies the order ... from DB/jpox, 
then managed repos, then a dummy model.  This resolver stack also has a 
listener setup that allows for just in time persistence of newly 
discovered models.  Very nice.


2) The choice of persistence engine (jpox) and insistence on using 
modello by other devs meant I couldn't use the maven/components model.


3) The model read / write via xpp3 was a PITA.
Archiva uses a proper SAX/DOM (and can even get around the mess 
that trygvis's name causes. ;-)
Archiva also uses xpath to load 3.0.0 and 4.0.0 into the same 
persisted model, making serving them out to m1 or m2 clients trivial.


I want to see maven 2.1 fixed in regards to project model resolution.  
The current mess in maven/components is completely unusable within 
archiva.  If that occurs, then the rest of the dependency graph 
resolution bits will fall into line easily.  (It did for archiva.)



- Jason has some code for graph-based resolution in 2.1, which will
supersede and replace the need for maven-dependency-tree
I based the archiva-dependency-graph entirely off of discussions with 
jason about how to do the dependency resolution bits.  I intentionally 
decoupled as much as I could to make the porting out of archiva easier.

I believe maven-dependency-tree is still relevant for 2.0.x and I will
continue to work on it since that's the version I'm targeting.  Once
the spec and implementation is done for 2.1, it should be very easy to
move these diagnostic tools over to use that instead.

- Joakim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-dependency-tree changes for 1.1

[Joakim Erdfelt]

The list of resolved dependencies is equivalent to what maven has.

And speaking of different resolutions, even now, maven 2.0.5 and 2.0.6 
resolve differently.   In my tests 2.0.6 does a worse job choosing the 
'latest' version of a dep when in conflict, maven 2.0.5 picks correctly.


When I say "more accurate" it doesn't mean that the it has a different 
list of deps, just more accurate as to where they come from.

A good example of this is direct dependencies that arrive in via Parent pom.
Under maven 2.0.5, they show as direct deps, under maven 2.0.6 it shows 
up as transitive (seems to only occure if that same dep shows up as a 
transitive dep later on)


The implementation on archiva side shows it as direct (which it should 
be).  Hence more accurate.  Not different.


I've also seen maven choose different deps during a conflict based on 
the order of the deps in the dependency list.  A common one i keep 
hitting is the xml-apis version, maven 2.0.6 chooses (incorrectly) the 
1.0.x series, when in the same tree 1.3.x series is available (and 
usually closer to the project than the 1.0.x series).


If you perform the dependency-tree lookup using a plugin or report, you 
can get different results than if you run it standalone (not within the 
maven execution environment).  I suspect that this is due to the 
existence of the maven core components within the $M2_HOME/lib that 
overrides whatever version you specify in the plugin.


In short.  The archiva one is consistent to compile / test scoped deps 
that maven client uses for the same project.  I even created an 
archivadev:create-dependency-tests plugin to take the 
shared-dependency-tree results of the project, and generate testcases 
that ensure an identical resolution of artifacts.


- Joakim Erdfelt


Carlos Sanchez wrote:

On 6/19/07, Mark Hobson <[EMAIL PROTECTED]> wrote:

Hi Joakim,

On 19/06/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> Note, Archiva couldn't use the DependencyTree component, as it made
> assumptions about repository access, availability, search order, and
> layout that simply were not true. (actually, this is a problem 
mostly in

> maven/components, but it still affected Archiva).
>
> So, we wrote our own dependency graph / tree routines.  It's more
> flexible, more reliable, faster, uses less memory, and more accurate
> than the ones in maven components (and the shared dependency tree
> component too).  I even utilized a local version of select classes 
from
> plexus-graph (that Jason wants to eventually use for dependency 
management).

>
> Check it out: archiva-dependency-graph
[snip]

Ah thanks, I wasn't aware of that - I had assumed archiva used
dependency-tree, although I haven't got around to looking at archiva
yet.  That certainly looks like the kind of code I was heading towards
- I'll have a proper look and get back to you.  I'm just wondering how
it could be more accurate than the resolution process that Maven core
uses itself?


what would be the point of having a different resolution than the one
maven uses? If I see a dependency graph different of what maven uses
it would be really confusing

other than that let's just choose one of the libraries and deprecate
the other one to avoid splitting the work



> I welcome you to look at it as a potential PoC for dependency handling
> in maven 2.1.
>
> It needs better non-javadoc documentation, but that'll come.

Cool.  Jason was talking about committing some artifact resolution
code this weekend, so hopefully we can start to converge these efforts
towards 2.1.

> BTW. I wrote a VersionComparator that uses logic version sorting 
too in

> Archiva.  I didn't realize it was a tough thing to do, until I read
> Kenney's email about versioning
> <http://www.nabble.com/versioning-tf2842865s177.html#a7938087>.
>
> Check it out: VersionComparator.java
> 
<https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/VersionComparator.java> 



Nice, I'd definitely like to see Kenney's versioning become the default.

Cheers,

Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-dependency-tree changes for 1.1

[Joakim Erdfelt]

Note, Archiva couldn't use the DependencyTree component, as it made 
assumptions about repository access, availability, search order, and 
layout that simply were not true. (actually, this is a problem mostly in 
maven/components, but it still affected Archiva).


So, we wrote our own dependency graph / tree routines.  It's more 
flexible, more reliable, faster, uses less memory, and more accurate 
than the ones in maven components (and the shared dependency tree 
component too).  I even utilized a local version of select classes from 
plexus-graph (that Jason wants to eventually use for dependency management).


Check it out: archiva-dependency-graph 

Especially the factory/facade class: DependencyGraphFactory.java 



I welcome you to look at it as a potential PoC for dependency handling 
in maven 2.1.


It needs better non-javadoc documentation, but that'll come.

BTW. I wrote a VersionComparator that uses logic version sorting too in 
Archiva.  I didn't realize it was a tough thing to do, until I read 
Kenney's email about versioning 
.


Check it out: VersionComparator.java 



- Joakim


Mark Hobson wrote:

Hi Kenney,

On 16/06/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:

Hi,

Just a quick question as to what this is for?


maven-dependency-tree is the shared component for computing dependency
trees from Maven's artifact resolution.  The original code came from
project-info-reports:dependencies, which I extracted for reuse by
help:dependencies.


Is it used in 'help:dependencies'?


It was, although I've now moved help:dependencies to dependency:tree
after a recent discussion.


Is it/will it be used in maven-core?


It isn't at the moment, but I assume it will be replaced with the
graph based artifact resolution being discussed for 2.1.

I see the dependency plugin uses both dependency-tree and 
dependency-analyzer,

what's the relation?


dependency-tree is as described above; dependency-analyzer performs a
bytecode analysis of compiled classes and determines which of the
declared and transitive dependencies are actually used.

If maven core eventually uses this, shouldn't it be moved into 
maven-components?


Possibly, although I'd have thought the new artifact resolution for
2.1 would supersede this.

The help:dependencies goal shows a tree of dependencies, and it 
didn't work too
well because the algorithm used there didn't match the internal 
algorithm from
maven itself, so the report was quite useless. Is this an attempt to 
fix that?


I assume you're talking about MDEP-97.  See my comment in that issue,
but yes, the aim for this component is to accurately reflect what is
happening within Maven.

Hope this helps,

Mark




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven 2.0.7

[Joakim Erdfelt]

Jason van Zyl wrote:


On 14 Jun 07, at 7:14 AM 14 Jun 07, Wendy Smoak wrote:


On 6/14/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


All the new stuff is here:

http://people.apache.org/~jvanzyl/


Is there a buildable-from-source distribution?

I only see -bin here: http://people.apache.org/~jvanzyl/maven-2.0.7/



We've never had one, but I can certainly make one by exporting the tag 
and zipping it up. All the source archives to date are simply the 
source as record, they don't include anything in there to build them. 
I don't think this is useful at all to anyone but if it's a legal 
requirement to have a buildable-from-source distribution it will take 
me a few minutes to make it. I'm not sure Maven SCM supports and 
export that would work and I'm certainly not going to mess around with 
that at this stage to put in the build. But if we want to give people 
what I actually used to build the release then the tag should be 
exported and zipped up.



Last one I see is maven-2.0.5
http://www.apache.org/dist/maven/source/

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven 2.0.7

[Joakim Erdfelt]

-1 (conditional)

evoking the spirit of dkulp ...

1) The embedded maven-core-2.0.7-uber.jar has bad LICENSE.txt and 
NOTICE.txt files.
1a) The LICENSE.txt at the root of the maven-core-2.0.7-uber.jar is for 
JSch's LGPL license. not ASL.

1b) There is no NOTICE.txt file at the root.
1c) There is a META-INF/NOTICE.txt file, but it only mentioned 
wagon-file provider.

1d) The META-INF/MANIFEST.MF was built by me!? huh?

Aside: With this new uber-jar setup, can we include wagon-webdav now?

- Joakim

Jason van Zyl wrote:

Hi,

The release notes are here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=13138 



The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/

Staging repository:

http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/maven-2.0.7/

Thanks,

Jason.



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




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

IT0121 - was ( Re: Dawn of the MNG-1577 )

[Joakim Erdfelt]

chneider <[EMAIL PROTECTED]> wrote:
> > I guess I am on the fence as to whether 2.0 is the correct 
version of D

> for
> > A to get.
> >
> > While B declares version 2.0 in its depMan section, we can't 
really be

> sure
> > of the intention of the developer if there is not a direct 
dependency on

> D
> > also listed in B.  Maybe B is a parent project to X, Y, & Z -- 
they need

> > version 2.0 of D, and this is the only reason B lists D in depMan.
> >
> > From the example project, we can't be sure that B really cares 
which

> version
> > of D it gets, because it has no direct dependency on D.
> >
> >
> > On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> > >
> > > Sorry for the 1950's Horror Movie Catchphrase. I'm just odd 
like that.

> ;-)
> > >
> > > The following has been filed as
> http://jira.codehaus.org/browse/MNG-3038
> > > and I encourage discussion on this.
> > >
> > > I was recently working out some discrepancies between what maven
> client,
> > > mpir and archiva show as dependency tree's on some projects, and
> > > discovered something.
> > >
> > > MNG-1577 as discussed isn't done (yet).
> > >
> > > I created the teeny example project following the example that 
Carlos

> > > described on
> > >
> > >
> > >
> 
http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html 


> > >
> > > | What about this use case for transitive 
dependencyManagement? has

> been
> > > tested?
> > > |
> > > | A -> B -> C -> D
> > > |
> > > | C depends on D 1.0
> > > | B has D 2.0 in dependencyManagement, no D in dependencies
> > > |
> > > | A should get D 2.0
> > >
> > > Source for project:
> > >   
http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz

> > >
> > > I found that maven 2.0.6 does not handle this use case.
> > >
> > > When working on project A, i was expecting to see module D 
version 2.0

> > > in use, but didn't.
> > > Here's what I see in mvn -X clean package of module A.
> > >
> > > [DEBUG] net.example:A:jar:1.0 (selected for null)
> > > [DEBUG] Adding managed depedendencies for net.example:B
> > > [DEBUG]   net.example:D:jar:2.0
> > > [DEBUG]   net.example:B:jar:1.0:compile (selected for compile)
> > > [DEBUG] net.example:C:jar:1.0:compile (selected for compile)
> > > [DEBUG]   net.example:D:jar:1.0:compile (selected for 
compile)

> > >
> > > That shows that D:2.0 is identified as being part of depMan.
> > >
> > > [DEBUG] Configuring mojo
> > > 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' 
-->

> > > [DEBUG]   (f) basedir =
> > >
> 
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A 


> > > [DEBUG]   (f) buildDirectory =
> > >
> > >
> 
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target 


> > > [DEBUG]   (f) classpathElements =
> > >
> > >
> 
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target/classes, 


> > > /home/joakim/.m2/repository/net/example/D/1.0/D-1.0.jar,
> > > /home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar,
> > > /home/joakim/.m2/repository/net/example/C/1.0/C-1.0.jar]
> > > [DEBUG]   (f) compileSourceRoots =
> > >
> > >
> 
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/src/main/java] 


> > > [DEBUG]   (f) compilerId = javac
> > > [DEBUG]   (f) debug = true
> > >
> > > That shows that the compiler plugin is using D:1.0 as part of the
> > > compiler plugin.
> > >
> > > This has been reviewed by Carlos and Brian on irc as not 
implemented

> > > correctly on maven client.
> > >
> > > --
> > > - Joakim Erdfelt
> > >   [EMAIL PROTECTED]
> > >   Open Source Software (OSS) Developer
> > >
> > >
> > > 
-

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






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

[Joakim Erdfelt]

I'm still not 100% sure that's the case.
I am working from the point of view of Archiva on this.
And in that case, the versioning of the various maven-* artifacts are 
important.


I seem to recall that the versions in $MAVEN_HOME/bin/lib always 
override what is in the plugins.

But this new shaded distribution of maven client might change that behavior.
I need to do more testing.

- Joakim

Carlos Sanchez wrote:

and the other important thing you raised up is that for the reports to
be right the plugins need to be using 2.0.6 libraries too, or we'll
get different reports than the actual behavior

On 6/6/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like 
that. ;-)


The following has been filed as http://jira.codehaus.org/browse/MNG-3038
and I encourage discussion on this.

I was recently working out some discrepancies between what maven client,
mpir and archiva show as dependency tree's on some projects, and
discovered something.

MNG-1577 as discussed isn't done (yet).

I created the teeny example project following the example that Carlos
described on

http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html 



| What about this use case for transitive dependencyManagement? has been
tested?
|
| A -> B -> C -> D
|
| C depends on D 1.0
| B has D 2.0 in dependencyManagement, no D in dependencies
|
| A should get D 2.0

Source for project:
  http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz

I found that maven 2.0.6 does not handle this use case.

When working on project A, i was expecting to see module D version 2.0
in use, but didn't.
Here's what I see in mvn -X clean package of module A.

[DEBUG] net.example:A:jar:1.0 (selected for null)
[DEBUG] Adding managed depedendencies for net.example:B
[DEBUG]   net.example:D:jar:2.0
[DEBUG]   net.example:B:jar:1.0:compile (selected for compile)
[DEBUG] net.example:C:jar:1.0:compile (selected for compile)
[DEBUG]   net.example:D:jar:1.0:compile (selected for compile)

That shows that D:2.0 is identified as being part of depMan.

[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
[DEBUG]   (f) basedir =
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A 


[DEBUG]   (f) buildDirectory =
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target 


[DEBUG]   (f) classpathElements =
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target/classes, 


/home/joakim/.m2/repository/net/example/D/1.0/D-1.0.jar,
/home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar,
/home/joakim/.m2/repository/net/example/C/1.0/C-1.0.jar]
[DEBUG]   (f) compileSourceRoots =
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/src/main/java] 


[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true

That shows that the compiler plugin is using D:1.0 as part of the
compiler plugin.

This has been reviewed by Carlos and Brian on irc as not implemented
correctly on maven client.

--
- Joakim Erdfelt
  [EMAIL PROTECTED]
  Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

When There's No More Room In Jiragoon, The Closed Will Walk Among Us: Dawn of the MNG-1577!

[Joakim Erdfelt]

Sorry for the 1950's Horror Movie Catchphrase. I'm just odd like that. ;-)

The following has been filed as http://jira.codehaus.org/browse/MNG-3038
and I encourage discussion on this.

I was recently working out some discrepancies between what maven client, 
mpir and archiva show as dependency tree's on some projects, and 
discovered something.


MNG-1577 as discussed isn't done (yet).

I created the teeny example project following the example that Carlos 
described on
 
http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html


| What about this use case for transitive dependencyManagement? has been 
tested?

|
| A -> B -> C -> D
|
| C depends on D 1.0
| B has D 2.0 in dependencyManagement, no D in dependencies
|
| A should get D 2.0

Source for project:
 http://joakim.erdfelt.com/maven/carlos_transitive_version.tar.gz

I found that maven 2.0.6 does not handle this use case.

When working on project A, i was expecting to see module D version 2.0 
in use, but didn't.

Here's what I see in mvn -X clean package of module A.

[DEBUG] net.example:A:jar:1.0 (selected for null)
[DEBUG] Adding managed depedendencies for net.example:B
[DEBUG]   net.example:D:jar:2.0
[DEBUG]   net.example:B:jar:1.0:compile (selected for compile)
[DEBUG] net.example:C:jar:1.0:compile (selected for compile)
[DEBUG]   net.example:D:jar:1.0:compile (selected for compile)

That shows that D:2.0 is identified as being part of depMan.

[DEBUG] Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
[DEBUG]   (f) basedir = 
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A
[DEBUG]   (f) buildDirectory = 
/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target
[DEBUG]   (f) classpathElements = 
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/target/classes, 
/home/joakim/.m2/repository/net/example/D/1.0/D-1.0.jar,
/home/joakim/.m2/repository/net/example/B/1.0/B-1.0.jar, 
/home/joakim/.m2/repository/net/example/C/1.0/C-1.0.jar]
[DEBUG]   (f) compileSourceRoots = 
[/home/joakim/code/experiments/deptree-mng-1577/carlos_transitive_version/A/src/main/java]

[DEBUG]   (f) compilerId = javac
[DEBUG]   (f) debug = true

That shows that the compiler plugin is using D:1.0 as part of the 
compiler plugin.


This has been reviewed by Carlos and Brian on irc as not implemented 
correctly on maven client.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

absconding GET from webdav - was ( Re: service layer API proposal )

[Joakim Erdfelt]

Second is the assumption that "GET" requests are not webdav requests.

Some WebDav client implementations improperly use the "GET" request to 
obtain file/folder information. (they should be using the various 
xml/propget requests to obtain that list.)


We could likely make it work, but in the process would reduce our 
already limited list of webdav clients down further.


/me glares at OSX.

(OSX's webdav client cannot be used against Archiva, due to bugs in the 
client)


- Joakim

Brett Porter wrote:

I agree. Any reason we can't use detection?

Also, any reason why the handler for downloading from the /repository/ 
can't be this get servlet instead of dav servlet? We probably don't 
want to add new ways to download from the repository for the same 
reason we removed /proxy/. I realise you can only map one servlet, but 
the servlet could delegate all operations other than get() to the dav 
implementation.


Anyway, not really sure of the implementation, just don't like 'get' 
as a name :)


I also don't agree on the repository storage format. I don't see any 
reason this can't be configurable, and I think it's useful to be able 
to run on an existing repo, or should we ever change the m2 format in 
future.


- Brett

On 06/06/2007, at 4:18 AM, nicolas de loof wrote:


The "/get/{implementation-id}/{layout-path}" is an interesting option.

Where would you place the target managed repository in such an URL ?

The only thing I don't like in this solution is that it doesn't work 
based

on an auto-detection of the requested format. I'd prefer the servlet to
search for an implementation that accepts the requested path, so that 
the
current "/repository/id/{layout}" would be valid for any supported 
layout.



2007/6/5, Joakim Erdfelt <[EMAIL PROTECTED]>:


We have 2 concepts that are co-mingled right now.

1) Getting an artifact from Archiva.
2) Deploying an artifact to Archiva.

This proposal should focus on #1, Getting an artifact from Archiva.
(As for #2, that can remain the realm of the current DavServlet
implementation)

I always pictured this as a new GetArtifactServlet.

Lets say we have it mapped to the "/get" servlet mapping.
The following urls would all point to the same artifact.

: Basic Format for maven 1 clients.

http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar 


: Basic Format for maven 2 clients.

http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar 



: (Advanced / Future Use) apt/deb serving.

http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb 


: (Advanced / Future Use) yum/rpm serving.

http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm 



Using a new servlet, would essentially decouple the filesystem
format/layout as a requirement.
Archiva can assume maven 2 format for the filesystem, and serve the
artifact to the client in the way that is requested.  After all the 
artifact
information is now in the database.  It makes sense to me to do it 
this way.


The idea with the URL format is that
"/get/{implementation-id}/{artifact-reference-implementation-format}"

The implementation id can be a plexus role-hint on the 
implementation of

this GetArtifactServlet.

What do you think?

- Joakim

nicolas de loof wrote:

Hello,

To enhance archiva-1.0 support for maven1, I'd like to introduce a 
layer

between DavServlet and repository proxies connectors.
As Joakim suggested, this is the scope of the Dynamic Artifact Serving
Layer
in archiva roadmap.

I propose this API :

public interface ArtifactServingLayer
{
   /**
* Retrieve an artifact path in the repository based on the resource
string.
*/
   public String getResourcePath( String resource );
}

The serving layer is responsible of finding the resource in the managed
repository, with any required logic or temporary content, and to give a
repository-related path back to the DavServer.

The default implementation could simply use proxies-connectors to 
find the


resource, and some interceptors / proxies could add features, like
converting on-the-fly from a layout format to the managedRepository
layout,
handle artifact relocation when a non-POM artifact is requested, or
anything
we discover to be usefull.

What's your opinion ?

Re: service layer API proposal

[Joakim Erdfelt]

Splitting up this discussion ...

First is the "detection" of clients.
Archiva has to manage not only the artifact, but also the pom/model 
version too.


Example:
A maven 2 client can request either of these format URLs.
http://machine.com/repository/internal/commons-lang/poms/commons-lang-2.1.pom
http://machine.com/repository/internal/commons-lang/commons-lang/2.1/commons-lang-2.1.pom

On maven 2, these can both be of model version 4.0.0 and it'll work.
On maven 1, these have to be model version 3.0.0 to work.

Oh if only the client could identify itself, then wouldn't be a problem. :-)

The reason for the "/get/{implementation-id}/{layout-path}" is to 
clearly identify the intent of the client, and 
compensate/migrate/regenerate/translate  the requested resource for the 
client.  It is clear, not overloaded.


As it stands now, the bidirectional layout has a tough time with maven 1 
layout requests of non-typical artifact types (seen commonly in 
corporate environments).  The lack of a 1::1 relationship between file 
extension and artifact type makes things even more difficult for 
"detection".


In short, I thoroughly dislike the idea of detecting the serving layer 
based on path information.
I see it as a band-aide, a short term solution, one that will cause a 
mess of spaghetti code in the Repository servlet.


When we move to other artifact providing concepts, yum/apt/osgi, etc... 
there is tremendous overlap on the path structure, so much so that this 
detection route is just a dead-end to me.


- Joakim

Brett Porter wrote:

I agree. Any reason we can't use detection?

Also, any reason why the handler for downloading from the /repository/ 
can't be this get servlet instead of dav servlet? We probably don't 
want to add new ways to download from the repository for the same 
reason we removed /proxy/. I realise you can only map one servlet, but 
the servlet could delegate all operations other than get() to the dav 
implementation.


Anyway, not really sure of the implementation, just don't like 'get' 
as a name :)


I also don't agree on the repository storage format. I don't see any 
reason this can't be configurable, and I think it's useful to be able 
to run on an existing repo, or should we ever change the m2 format in 
future.


- Brett

On 06/06/2007, at 4:18 AM, nicolas de loof wrote:


The "/get/{implementation-id}/{layout-path}" is an interesting option.

Where would you place the target managed repository in such an URL ?

The only thing I don't like in this solution is that it doesn't work 
based

on an auto-detection of the requested format. I'd prefer the servlet to
search for an implementation that accepts the requested path, so that 
the
current "/repository/id/{layout}" would be valid for any supported 
layout.



2007/6/5, Joakim Erdfelt <[EMAIL PROTECTED]>:


We have 2 concepts that are co-mingled right now.

1) Getting an artifact from Archiva.
2) Deploying an artifact to Archiva.

This proposal should focus on #1, Getting an artifact from Archiva.
(As for #2, that can remain the realm of the current DavServlet
implementation)

I always pictured this as a new GetArtifactServlet.

Lets say we have it mapped to the "/get" servlet mapping.
The following urls would all point to the same artifact.

: Basic Format for maven 1 clients.

http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar 


: Basic Format for maven 2 clients.

http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar 



: (Advanced / Future Use) apt/deb serving.

http://hostname.com/archiva/get/apt-deb/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.deb 


: (Advanced / Future Use) yum/rpm serving.

http://hostname.com/archiva/get/yum-rpm/org.apache.maven.wagon/wagon-scm-1.0-alpha-3.rpm 



Using a new servlet, would essentially decouple the filesystem
format/layout as a requirement.
Archiva can assume maven 2 format for the filesystem, and serve the
artifact to the client in the way that is requested.  After all the 
artifact
information is now in the database.  It makes sense to me to do it 
this way.


The idea with the URL format is that
"/get/{implementation-id}/{artifact-reference-implementation-format}"

The implementation id can be a plexus role-hint on the 
implementation of

this GetArtifactServlet.

What do you think?

- Joakim

nicolas de loof wrote:

Hello,

To enhance archiva-1.0 support for maven1, I'd like to introduce a 
layer

between DavServlet and repository proxies connectors.
As Joakim suggested, this is the scope of the Dynamic Artifact Serving
Layer
in archiva roadmap.

I propose this API :

public interface ArtifactServingLayer
{
   /**
* Retrieve an artifact path in the repository based on the resource
string.
*/
   public String getResource

[RESULTS] [VOTE] Release Archiva 1.0-alpha-1

[Joakim Erdfelt]

The following are the results of this vote.

+5 Binding Votes ( Jesse, Emmanuel, Wendy, Fabrice, and Myself)
+2 Non-binding Votes (Maria, and Nicolas)

The release is good to go.
I'll send another update when it has been completed.

- Joakim

Joakim Erdfelt wrote:

Archiva 1.0-alpha-1 was tagged and built this afternoon.

The proposed distribution, including binary distributions, and
signatures can be found here:

 http://people.apache.org/builds/maven/archiva/1.0-alpha-1/

To keep up with the trend started by Wendy Smoak (sorta):
The 1.0-alpha-1 staged copy was setup and configured to point to
a pre-built repository, and then used to build the next archiva
snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.

This will be Archiva's first release with a proper database, and
is intended to get a testable baseline of the archiva feature set
into the hands of all interested individuals.

The list of issues identified and closed with this release can
be found below:

 Archiva 1.0-alpha-1 Release Notes:
 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443 



This is an alpha release, and as such, has bugs.

Once people have a chance to kick the prototype tires, and look around,
the most urgent jira tickets will be addressed quickly for a 1.0-alpha-2
release, with an expected release 1 to 2 weeks after this one.

Known issues include documentation, problems with proxying, problems
running the webapp on Tomcat, missing reporting, empty or inaccurate
dependency tree information, and poor grammar.
These and other issues can be tracked at the URL below:

 Archiva 1.0-alpha-2 Open Issues:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518 



Once you have had a chance to examine the distribution, please cast
your vote.  We welcome votes and feedback from all community members.

[ ]  +1  Release it!
[ ]   0
[ ]  -1  Don't release it, because...

72 hours ends Monday afternoon (GMT -5)
If you need more time, just ask.

Re: [VOTE] Release Archiva 1.0-alpha-1

[Joakim Erdfelt]

I don't like hooking up the webdav interface into the dynamic artifact 
serving.
I think we need to investigate the DASL layer idea in the Archiva 
Roadmap, maybe move it up in priority.


http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap

- Joakim

nicolas de loof wrote:
I allready noticed this no-update-check issue on 0.9 in MRM-320, but 
maybe I

wasn't clear as it was closed as "won't fix".

I'm looking for a clean way to pre-process the DAV request before proxies
connectors get fetched. This could include the legacy -> default (or any
other) request path layout conversion. For now, the only way I've 
found is

to add some code in ProxiedDavServer.

Could ArtifactReference, VersionedReference and ProjectReference share an
ancestor so that we can refactor BidirectionalRepositoryLayout to only
provide toReference(path) and toPath(Reference) ? This would avoid having
similar try/catch 3 times.



2007/6/5, Joakim Erdfelt <[EMAIL PROTECTED]>:


MRM-412 will make it into Archiva 1.0-alpha-2 thanks!

As for the check for the requested file issue, yes that is a mistake,
likely left over from an earlier time, when things were more chaotic, a
time when great herds of horned alpacas roamed the earth.

- Joakim

nicolas de loof wrote:
> I just submitted MRM-412 and attached a patch.
>
> This issue adds support for any layout to the DavServlet :
> Requesting "/javax.servlet/jars/servlet-api-2.3.jar" or
> "/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar" will auto-detect
the
> layout used for the request (based on configured layouts in archiva)
> and use
> it to build the ArchivaArtifact object.
> This requires the BidirectionalRepositoryLayout interface to be
> enhanced to
> add detection of valid path.
>
> please review.
>
>
> I also notice the ProxiedDavServer does check for the requested 
file to
> exist in managed repo before trying to proxy it. Doesn't this 
bypass any

> update strategy configured in proxies ? Perhaps I missed something ?
>
>
> 2007/6/4, Joakim Erdfelt <[EMAIL PROTECTED]>:
>>
>> doh!  *I* never voted on this. :-)
>>
>> +1 to release.
>>
>> - Joakim
>>
>> Joakim Erdfelt wrote:
>> > Archiva 1.0-alpha-1 was tagged and built this afternoon.
>> >
>> > The proposed distribution, including binary distributions, and
>> > signatures can be found here:
>> >
>> >  http://people.apache.org/builds/maven/archiva/1.0-alpha-1/
>> >
>> > To keep up with the trend started by Wendy Smoak (sorta):
>> > The 1.0-alpha-1 staged copy was setup and configured to point to
>> > a pre-built repository, and then used to build the next archiva
>> > snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.
>> >
>> > This will be Archiva's first release with a proper database, and
>> > is intended to get a testable baseline of the archiva feature set
>> > into the hands of all interested individuals.
>> >
>> > The list of issues identified and closed with this release can
>> > be found below:
>> >
>> >  Archiva 1.0-alpha-1 Release Notes:
>> >
>> >
>>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443 


>>
>> >
>> >
>> > This is an alpha release, and as such, has bugs.
>> >
>> > Once people have a chance to kick the prototype tires, and look
>> around,
>> > the most urgent jira tickets will be addressed quickly for a
>> 1.0-alpha-2
>> > release, with an expected release 1 to 2 weeks after this one.
>> >
>> > Known issues include documentation, problems with proxying, 
problems
>> > running the webapp on Tomcat, missing reporting, empty or 
inaccurate

>> > dependency tree information, and poor grammar.
>> > These and other issues can be tracked at the URL below:
>> >
>> >  Archiva 1.0-alpha-2 Open Issues:
>> >
>>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518 


>>
>> >
>> >
>> > Once you have had a chance to examine the distribution, please cast
>> > your vote.  We welcome votes and feedback from all community 
members.

>> >
>> > [ ]  +1  Release it!
>> > [ ]   0
>> > [ ]  -1  Don't release it, because...
>> >
>> > 72 hours ends Monday afternoon (GMT -5)
>> > If you need more time, just ask.
>> >
>>
>>
>> --
>> - Joakim Erdfelt
>>   Committer and PMC Member, Apache Maven
>>   Archiva Developer
>>   [EMAIL PROTECTED]
>>   [EMAIL PROTECTED]
>>   Alpaca Founding Member

Re: [jira] Closed: (MNG-671) implement a license clickthrough

[Joakim Erdfelt]

How about a vote? ;-)
+1 to reopening of MNG-671

- Joakim

Brett Porter wrote:

I disagree. What sacred ritual must I perform to reopen this?

- Brett

On 03/06/2007, at 7:08 AM, Jason van Zyl (JIRA) wrote:



 [ 
http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]


Jason van Zyl closed MNG-671.
-


Yah, I don't think this is a burning issue anymore. At least not with 
respect to click through license handling of things like hibernate 
which maven is just going to take from the repository (I don't know 
what the status is now honestly) and there are impls of things like 
JavaMail/Activation now. So we'll let this one rest for now.



implement a license clickthrough


Key: MNG-671
URL: http://jira.codehaus.org/browse/MNG-671
Project: Maven 2
 Issue Type: New Feature
   Reporter: Brett Porter
Fix For: 2.1.x

Attachments: maven-artifact-manager-patch-2.txt, 
maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, 
maven-license-patches-3.zip, maven-settings-patch-2.txt, 
maven-settings-patch.txt



we need some basic license acceptance policy for downloadable 
artifacts. For now, this can just be a Y/N that is saved forever.


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the 
administrators: http://jira.codehaus.org/secure/Administrators.jspa

-
For more information on JIRA, see: 
http://www.atlassian.com/software/jira





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] Change project names for M1 plugins in JIRA

[Joakim Erdfelt]

+1

- Joakim

John Casey wrote:

+1

On May 30, 2007, at 11:27 AM, Dennis Lundberg wrote:


Hi

We get some JIRA issues for the M1 plugins that really belongs to the 
M2 plugins. To help get these issues into the correct JIRA project 
from the start, I propose that we change the names of the JIRA 
projects for M1 plugins. From "maven-idea-plugin" to "Maven 1.x IDEA 
Plugin".


Note: for the M2 plugins we use names like "Maven 2.x IDEA Plugin".

I am willing to do the actual changes if you like this proposal.

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Preparing for maven-artifact-converter and maven-transaction release vote.

[Joakim Erdfelt]

Wow. so little interest in these 2 modules. :-(

These were ripped out of archiva on request by Jason van Zyl.
After a quick chat on IRC today, it was decided that since his plans for 
the module have changed, and it is best if we fold these modules back 
into archiva (where they originated).


I will be doing the following ...

* Moving the svn codebase to archiva/trunk
* Removing the svn tags for both modules
* Removing the staged copies of these modules.
* Moving package from org.apache.maven.shared to 
org.apache.maven.archiva.converter


- Joakim

Brett Porter wrote:

Sorry, I'm confused - why alpha-1? wasn't the model 2.1?

IF these are meant to be released in lockstep, they should probably be 
in a module together.


- Brett

On 26/05/2007, at 9:08 AM, Joakim Erdfelt wrote:

I'm preparing the staging / tags / etc... for the following two 
shared modules ...


maven-artifact-converter
 snapshot version: 2.0.5-SNAPSHOT
 proposed version: 2.1-alpha-1-SNAPSHOT

 The oddball jump in versioning is to keep it in sync with the 
maven-model-converter release

 which maven-artifact-converter depends on.

and

maven-transaction
 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction
 snapshot version: 1.0-SNAPSHOT
 proposed version: 1.0-alpha-1

(These two modules need releasing in order to move along a pending 
release of Archiva)


--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


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




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Maven PMC welcomes Wendy Smoak

[Joakim Erdfelt]

Congrats! and Welcome!

-Joakim

Brett Porter wrote:

Hi all,

The Maven PMC has voted to add Wendy Smoak to the PMC. Please join me 
in welcoming her!


Cheers,
Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release maven-artifact-converter 2.1-alpha-1 / maven-transaction 1.0-alpha-1

[Joakim Erdfelt]

Greetings!

I'd like to release the following 2 maven shared modules.

maven-artifact-converter - 2.1-alpha-1
 svn::  
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-artifact-converter
 tag::  
https://svn.apache.org/repos/asf/maven/shared/tags/maven-artifact-converter-2.1-alpha-1


maven-transaction - 1.0-alpha-1
 svn::  
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction
 tag::  
https://svn.apache.org/repos/asf/maven/shared/tags/maven-transaction-1.0-alpha-1



You can find the staged version of these modules at
http://people.apache.org/~joakime/stage/maven_shared_repo/

So, let's try 72h +1/+0/-1. Please cast your votes!

Here my +1

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Preparing for maven-artifact-converter and maven-transaction release vote.

[Joakim Erdfelt]

I'm preparing the staging / tags / etc... for the following two shared 
modules ...


maven-artifact-converter
 snapshot version: 2.0.5-SNAPSHOT
 proposed version: 2.1-alpha-1-SNAPSHOT

 The oddball jump in versioning is to keep it in sync with the 
maven-model-converter release

 which maven-artifact-converter depends on.

and

maven-transaction
 https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction
 snapshot version: 1.0-SNAPSHOT
 proposed version: 1.0-alpha-1

(These two modules need releasing in order to move along a pending 
release of Archiva)


--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 Open Source Software (OSS) Developer


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[discussion] archiva-site & version specific documentation.

[Joakim Erdfelt]

I'd like to get a discussion going on how to tackle the documentation 
present on the site.


:: Javadoc distribution and role ::

I'm a firm believer that the javadoc for a project should be versioned 
and always available, even for back versions.
If we use http://jakarta.apache.org/commons/collections/ as a good 
example of this, you'll see that javadoc for version 2.1.1, 3.2, and 
SVN-Latest are all available online.


Course, this makes more sense with a library that gets reused, than a 
webapp.


I'd like to make the top level aggregated javadoc be versioned into a 
neutral (stripped of alpha, beta, rc, SNAPSHOT, etc..) url path, but the 
actual generated javadoc contain the those stripped identifiers.


So, archiva-0.9 branch (0.9-alpha-3-SNAPSHOT) goes into 
http://maven.apache.org/archiva/apidoc/0.9/
and archiva trunk (1.0-alpha-1-SNAPSHOT) goes into 
http://maven.apache.org/archiva/apidoc/1.0/


I'd also like to get as many of the concept details into the javadoc, vs 
the site, just to maintain the version specific nature of the documentation.


The per module javadoc.jar files should still be generated and deployed 
for the benefit of the IDE users.


:: The archiva-site module ::

Ultimately, this module is really archiva version independent.

Should we try to move this module out of the tree into it's own top level?
Or should we just treat the one in trunk as the 'current' version that 
exists on http://maven.apache.org/archiva/ ?


Should we have version specific documentation sections on the left hand 
navigation menu?
Or should we have basic menu options, with disambiguation portal pages 
to the specific versions?


Some documentation is not version specific, database setup, web 
container setup, purpose, configuration (to a limited degree),  getting 
started, FAQ, etc...


We can reference/link the latest released javadoc section for the 
details on that version.


Any comments?  Suggestion?  Hate Mail?  Silly Jokes?  Unrelated Arguments?

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 Archiva Developer
 Alpaca Founding Member 

Re: org.jpox.exceptions.ConnectionFactoryNotFoundException: Connection Factory

[Joakim Erdfelt]

I'm working on a fix for this.
It's due to a missing configuration / setup of a test local hsqldb.
The default construction of the JdoFactory is to use jndi, which is 
valid everywhere but in unit testing.


Jan Nielsen wrote:

Okay - a bit more information. I've updated to r5838983, using
Maven-2.0.6 and JDK 5 or 6 on Windows, but I still get the same
failure. It appears that the "default" JNDI context is not defined:

   protected void setUp()
   throws Exception
   {
   super.setUp();

   roleManager = (RoleManager) lookup( RoleManager.ROLE, "default" );
   }

To save me a bit of digging, does anyone know how this is supposed to 
work?



Thanks,

-Jan

--
- Joakim Erdfelt
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
 Archiva Developer
 Alpaca Founding Member 

Re: question about POMs in (new) trunk

[Joakim Erdfelt]

That's expected.

On a fresh checkout/update, the modules do not exist in the local (or 
remote) repositories yet.


When you run the eclipse:eclipse goal, it tries to resolve the 
dependencies, it can't as there is no information present in the 
repository system for those modules.


Compile it first,  then run eclipse:eclipse, then import it into eclipse.

- Joakim


nicolas de loof wrote:

You're right, I missed it.

This has a strange side effect : when I run mvn eclipse:eclipse from a 
fresh

checkout, all inter-modules dependencies are unresolved :

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT 



 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file
-DgroupId=org.apache.maven.archiva-DartifactId=archiva-database-consumers
\
 -Dversion=1.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1) 
org.apache.maven.archiva:archiva-webapp:war:1.0-alpha-1-SNAPSHOT

   2)
org.apache.maven.archiva:archiva-scheduled:jar:1.0-alpha-1-SNAPSHOT
   3)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT 


...


I can't import all modules in Eclipse before mvn install is successfull.
This may create issues if the code in SVN has compilation failures due to
some unfortunate commit.


2007/5/3, Andrew Williams <[EMAIL PROTECTED]>:


I have not looked, but am guessing there is a dependencyManagement
section in the parent pom.

Andy

On 3 May 2007, at 11:45, nicolas de loof wrote:

> The POMs in the new trunk don't set versions for dependencies on other
> arhiva modules. Maven has no issue with that when running mvn install.
>
> I tried to do the same on my project and got error :
> Validation Messages:
>
>[0]  'dependencies.dependency.version' is missing for
> com.capgemini.quickstart:quickstart-model
>
> Reason: Failed to validate POM
>
>
> I don't see any special version setting in archiva. Did I miss
> something ?
>
> Nico.

Complete: trunk version upgraded to 1.0-alpha-1-SNAPSHOT

[Joakim Erdfelt]

The merge is complete.
Trunk is now on version 1.0-alpha-1-SNAPSHOT using the former database 
branch.


Old trunk is now located in 
https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9


- Joakim

Joakim Erdfelt wrote:

Steps 1-4 are now complete.
Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ...

- Joakim

Joakim Erdfelt wrote:

Ok.

Here's the vote breakdown.

option A - Make the branch the new trunk.
* Emmanuel Venisse
* Arnaud Heriter
* Nicolas De Loof
* Jesse McConnell
* Brett Porter
* Wendy Smoak

option B - Merge the branch into the existing trunk.
* Maria Odea Ching

option C - Do not merge the branch into trunk.
* (n/a)

Looks like option A wins!

The current plan

1) Identify the changes since the branch has been made.
   Branch was created on March 15, 2007 - on revision 518676
2) Merge in changes made on trunk since branch into the branch.
3) Rename the current trunk as branch-0.9
4) Rename the archiva-jpox-database branch as the new trunk.
5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT
6) Announce completion of merge to archiva-dev
7) Continue working on admin screens.
8) Once admin screens are stable, get the ball rolling on a 
1.0-alpha-1 release.


- Joakim Erdfelt

Complete: update db-branch / trunk->branch-0.9 / db-branch->trunk swap

[Joakim Erdfelt]

Steps 1-4 are now complete.
Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ...

- Joakim

Joakim Erdfelt wrote:

Ok.

Here's the vote breakdown.

option A - Make the branch the new trunk.
* Emmanuel Venisse
* Arnaud Heriter
* Nicolas De Loof
* Jesse McConnell
* Brett Porter
* Wendy Smoak

option B - Merge the branch into the existing trunk.
* Maria Odea Ching

option C - Do not merge the branch into trunk.
* (n/a)

Looks like option A wins!

The current plan

1) Identify the changes since the branch has been made.
   Branch was created on March 15, 2007 - on revision 518676
2) Merge in changes made on trunk since branch into the branch.
3) Rename the current trunk as branch-0.9
4) Rename the archiva-jpox-database branch as the new trunk.
5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT
6) Announce completion of merge to archiva-dev
7) Continue working on admin screens.
8) Once admin screens are stable, get the ball rolling on a 
1.0-alpha-1 release.


- Joakim Erdfelt

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

[Joakim Erdfelt]

+1

- Joakim

Daniel Kulp wrote:
> I'd like to release version 1.0-alpha-5 of the 
> maven-remote-resources-plugin.   This resolves one critical bug, but 
> also adds some new features to make it a bit more usable.
>
>
> Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-5
>
> ** Bug
> * [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in 
> POM
>
> ** Improvement
> * [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files
> * [MRRESOURCES-20] - Support for binary resources
> * [MRRESOURCES-21] - Supplement the data model used by Velocity
>
>
> Staging area:
> http://people.apache.org/~dkulp/stage_remoteresources/
>
> Tag:
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-5/
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

State of the Archiva (April 2007)

[Joakim Erdfelt]

to database.
  b) Index artifact details (lucene)
  c) Validate repository metadata.
  d) Index archiva table of contents (lucene)
  e) Update bytecode information in artifact-java-details.
  f) Index public methods (lucene)
Processed Artifacts Stage:
  a) Artifact not present in filesystem, remove artifact from db.
  b) Artifact of type 'pom' not present in filesystem, remove project
 model from db
  c) Artifact not present in filesystem, remove from lucene index.

  The benefit of these stages is that it allows the content to be found on
  the filesystem and be made available to the users via the browse interface
  relatively quickly. (Takes about 6 minutes to scan all of ibiblio this
way)

  If a user happens to request an versioned project browse that has
  yet to undergo the Major Stage 2, a 'Just in Time' scan of that specific
  project is done.

  The repository scan has been changed to include all content "**/*" and
  specifically exclude known ignorable content. For each discovered file
  a determination is made to see if it falls into the Artifact list or
  the Content list, if it doesnt' fall into those two lists.

  The archiva.xml contains the lists of patterns for ...
a) Artifacts
b) Indexable Content
c) Auto-Remove
d) Ignored

  For latest, in code, lists see: http://tinyurl.com/2hbzoc

  CONSUMER API:

  This is a fundamental part of how archiva knows what to do with the
content
  it is tracking.

  We have 2 major consumer api interfaces.

  RepositoryContentConsumer - http://tinyurl.com/28roxn
This consumer interface is used for those consumers that want to operate
on the raw files in the repository filesystem.

  ArchivaArtifactConsumer   - http://tinyurl.com/2s2blk
This consumer interface is used for those consumers that want to operate
on artifacts.  Those consumers operating on the second major phase (as
outlined above as the Database Scan) should use this interface.

  This allows for a very simplified content scan and manipulation in
archiva.

- Joakim Erdfelt

Re: failure when serving maven2 plugin from a legacy repository

[Joakim Erdfelt]

That is a failure in the packaging <-> file extension mapping facilities
in archiva/trunk

Other examples (from codein archiva branch):
typeToExtensionMap.put( "ejb-client", "jar" );
typeToExtensionMap.put( "ejb", "jar" );
typeToExtensionMap.put( "distribution-tgz", "tar.gz" );
typeToExtensionMap.put( "distribution-zip", "zip" );
typeToExtensionMap.put( "java-source", "jar" );
typeToExtensionMap.put( "aspect", "jar" );
typeToExtensionMap.put( "uberjar", "jar" );
typeToExtensionMap.put( "maven-plugin", "jar" );
typeToExtensionMap.put( "maven-archetype", "jar" );

It (along with many other bugs) is being corrected in the archiva
database refactor branch (highly unstable ATM).

- Joakim

nicolas de loof wrote:
> I'm using archiva to proxy http://dist.codehaus.org (maven1-legacy
> repository)
>
> This repo contains xdoclet2 maven plugin :
> http://dist.codehaus.org/xdoclet/maven-plugins/
>
> Having configured archiva as a mirror, maven tries to download :
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.jar
>
> that fails.
>
> using
> http://archiva:8080/repository/maven/xdoclet/maven2-xdoclet2-plugin/2.0.5/maven2-xdoclet2-plugin-2.0.5.maven-pluginworks
>
> fine.
>
> What is the expected behaviour :
> 1 - shouldn't dist.codehaus.org use a "maven-plugins" type ?
> 2 - how could archiva now we are expecting a maven plugin ?
>
> For this second point, archiva could
> - use the "*-plugin" pattern to detect the expected type, but this looks
> like a hack
> - read the POM for the requested artifact to get the type. Looks
> better but
> more work to code...
>
> Any suggestion ?
>

Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and maven-enforcer-rule-api 1.0-alpha-1

[Joakim Erdfelt]

+1

btw, what is the scope of this plugin?
Does it exist to only check the environment of the user before executing
the build?
Can it also perform some multi-module sanity checks, or is that out of
scope?

(I've wanted to add 2 multi-module convergence checks, on dependencies
and parent references)

- Joakim

Jesse McConnell wrote:
> +1
>
> On 4/4/07, John Casey <[EMAIL PROTECTED]> wrote:
>> +1
>>
>> On 4/3/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>> >
>> > Only 1? I figured you'd be +1000 at least by now ;-)
>> >
>> > -Original Message-
>> > From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
>> > Dillon
>> > Sent: Tuesday, April 03, 2007 11:13 PM
>> > To: Maven Developers List
>> > Subject: Re: [VOTE] release maven-enforcer-plugin 1.0-alpha-1 and
>> > maven-enforcer-rule-api 1.0-alpha-1
>> >
>> > +1
>> >
>> > --jason
>> >
>> >
>> > On Apr 3, 2007, at 7:54 PM, Brian E. Fox wrote:
>> >
>> > > The maven-enforcer-plugin picks up where  leaves off
>> > > and
>> > > allows control over the maven, jdk and os versions of a build, as
>> well
>> > > as injection of custom rules.
>> > >
>> > > The deployments are staged here:
>> > > http://people.apache.org/~brianf/staging-repository
>> > >
>> > > The sites are deployed here:
>> > > http://maven.apache.org/plugins/maven-enforcer-plugin/
>> > > http://maven.apache.org/shared/maven-enforcer-rule-api/index.html
>> > >
>> > > As this is an initial release, there are no changes, but a Jira
>> > > project
>> > > does exist:
>> > > http://jira.codehaus.org/browse/MENFORCER
>> > >
>> > > This plugin was initially conceived here:
>> > > http://www.nabble.com/Control-of-maven-using-prerequisites-
>> > > tf3231437s177
>> > > .html#a8979318
>> > >
>> > > And here:
>> > > http://www.nabble.com/Why-is-prerequisites-not-inherited--
>> > > tf3236197s177.
>> > > html#a9016296
>> > >
>> > > Vote is open for 72hrs.
>> > >
>> > > +1
>> > >
>> > >
>> -
>> > > 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]
>> >
>> >
>> > -
>> > 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: [ANN] Maven 2.0.6 Released

[Joakim Erdfelt]

Jason van Zyl wrote:
>
> On 2 Apr 07, at 1:01 PM 2 Apr 07, Wendy Smoak wrote:
>
>> On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>> On 1 Apr 07, at 9:04 AM 1 Apr 07, Brett Porter wrote:
>>> > Should this include the full change log like previous releases?
>>>
>>> I added a pointer to the roadmap, I don't think we need to entirely
>>> replicate the list produced by JIRA. But users should be able to
>>> navigate from the release notes to the full list of fixes.
>>
>> IMO, the list needs to be in svn (and I added it).  JIRA issues can be
>> reopened and edited, and may disappear from the generated list.
>
> So then the pointers to those issues are just as meaningless. If you
> don't retain some integrity in the issue management system then what's
> the point really?
>
> Just copying text around doesn't have much value. I don't think it
> happens that often that an issue is removed. If any text is going to
> be added it should be the changes text with full descriptions. I don't
> see much use in copying text out of JIRA.
+1 for static release notes content.

I think that if a jira issue gets re-opened, then the linked jira report
will then be out of date.

Also, if a reorganization of the jira occurs, the release information is
lost too.
Also, if jira isn't available, the release notes are also not available.

I'm in favor of static release notes.

- Joakim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Creating a schedule for releases

[Joakim Erdfelt]

Looks like we'll need an new maven-ical-report for the site generation.

To inject the schedule into the site, with links to the live-schedule.

- Joakim

Jason van Zyl wrote:
>
> On 2 Apr 07, at 9:44 AM 2 Apr 07, Brian E. Fox wrote:
>
>> +1. More info helps the users to plan and gives the devs something to
>> work towards. I'd like to see some tentative plans for 2.1 also.
>>
>
> 2.1-alpha-1 will go on the schedule, the issues are registered for it
> and John and I would like to cut the alpha in the coming week so we'll
> get wiki fleshed out with details of the issues listed in JIRA.
>
> Jason.
>
>> -Original Message-
>> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
>> Sent: Monday, April 02, 2007 9:38 AM
>> To: Maven Developers List
>> Subject: Creating a schedule for releases
>>
>> Hi,
>>
>> Taking the lead from the Mylar development team, whom I have a great
>> deal of respect for, I would like to create a shared Google calendar
>> where we can put some releases on schedules. I know at least for
>> Maven itself, Doxia, Wagon and some plugins I'm working on I have a
>> clear idea of when they will be released. But what the Mylar team
>> does is work under the general Europa guidelines and they try and do
>> releases every 6 weeks. So I'm not sure how the everything will be
>> ultimately schedule but I would like to make a start at trying to
>> provide some transparency as the Mylar team does.
>>
>> So the though was that we would have a calendar on Google where
>> everyone on the PMC has access to the schedule (as it's a PMC person
>> who has to do a release) and I'll start the by putting in the Maven
>> releases. I planned 4 weeks between the last releases and it ended up
>> being 6 so I'll shoot for that again, but even if we're off a bit it
>> keeps the users informed and they will have a single place to look
>> for planned releases dates.
>>
>> I would like to set this up asap.
>>
>> +1
>>
>> Jason.
>>
>> -
>> 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]
>>
>>
>
>
> -
> 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: Creating a schedule for releases

[Joakim Erdfelt]

+1 Spiffy idea!

- Joakim

Jason van Zyl wrote:
> Hi,
>
> Taking the lead from the Mylar development team, whom I have a great
> deal of respect for, I would like to create a shared Google calendar
> where we can put some releases on schedules. I know at least for Maven
> itself, Doxia, Wagon and some plugins I'm working on I have a clear
> idea of when they will be released. But what the Mylar team does is
> work under the general Europa guidelines and they try and do releases
> every 6 weeks. So I'm not sure how the everything will be ultimately
> schedule but I would like to make a start at trying to provide some
> transparency as the Mylar team does.
>
> So the though was that we would have a calendar on Google where
> everyone on the PMC has access to the schedule (as it's a PMC person
> who has to do a release) and I'll start the by putting in the Maven
> releases. I planned 4 weeks between the last releases and it ended up
> being 6 so I'll shoot for that again, but even if we're off a bit it
> keeps the users informed and they will have a single place to look for
> planned releases dates.
>
> I would like to set this up asap.
>
> +1
>
> Jason.
>
> -
> 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 2.0.6

[Joakim Erdfelt]

+1 (a little late)

- Joakim

Jason van Zyl wrote:
> Hi,
>
> The roadmap is here:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10500&fixfor=13010
>
>
> The tag is here:
>
> http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.6/
>
> Staging repository:
>
> http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/
>
> And the distros you are interested in are here:
>
> http://people.apache.org/~jvanzyl/staging-repository/maven-2.0.6/org/apache/maven/maven-core/2.0.6/
>
>
> Thanks,
>
> Jason.
>
>
>
> -
> 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: HowTo avoid version number in filenames

[Joakim Erdfelt]

The fact that install / deploy process maintains the filename with a
version in it is simple.

The repository is to be thought of as a database.
The local repository is to be thought of as a remote repository cache.

The repository database *needs* versioning.

The plugins that bundle the artifacts within other files (such a
assembly, war, ear, etc...) honor the  setting when working
on the artifacts outside of the Repository database.

- Joakim

Stephane Nicoll wrote:
> Hi,
>
> On 3/28/07, Franz Allan Valencia See <[EMAIL PROTECTED]> wrote:
>> Good day to you, Dheeraj,
>>
>> Try
>>
>> 
>>   ...
>>   
>> ${artifactId}
>> ...
>>   
>>   ...
>> 
>>
>> By default, the value of finalName is "${artifactId}-${version}" (
>> without
>> the quotes ) which every pom inherits from the super pom ( see [1] ).
>
> This is not honored by the deploy/install plugins so I am not sure
> it's fixing anything.
>
>>
>> ..btw, you might want to try asking in the maven users list next time
>> to get
>> a faster response :)
>
> +1
>
> Stéphane
>
>
>>
>> Cheers,
>> Franz
>>
>> [1]
>> http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
>>
>> On 3/27/07, Pant, Dheeraj <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi,
>> >
>> > Using Maven generates all the artifacts (jars/wars/ears)
>> > with a unique filename -.. How do we remove
>> > the version number from the filenames? I need a generic way to do
>> this,
>> > because we have many sub-modules and would like to have a common
>> > solution that can be reused for every module.
>> >
>> >
>> >
>> > I tried the following things:
>> >
>> > 1. For ear, Maven allows to rename the modules.
>> >
>> > 2. Using an ant task, rename each jar/war/ear after it gets packaged.
>> >
>> >
>> >
>> > However, still classpath within the MANIFEST files (generated using
>> > Maven) refers to unique filenames including their version numbers. We
>> > don't want to hardcode our manifest files. I tried specifying project
>> > specific modules as system dependency - did not work.
>> >
>> >
>> >
>> > Is there a way out?
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Dheeraj.
>> >
>> >
>> >
>> >
>> >
>> > -
>> > This message and any attachments are intended only for the use of
>> > the addressee and may contain information that is privileged and
>> > confidential. If the reader of the message is not the intended
>> > recipient or an authorized representative of the intended
>> > recipient, you are hereby notified that any dissemination of this
>> > communication is strictly prohibited. If you have received this
>> > communication in error, notify the sender immediately by return
>> > email and delete the message and any attachments from your system.
>>
>
> -
> 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] maven-app-configuration and maven-shared-component parent release

[Joakim Erdfelt]

+1

- Joakim

Jesse McConnell wrote:
> As part of the prepwork for getting an actual continuum alpha release
> out I need to get a few more dependencies released, one of them is the
> maven-app-configuration.  And since the currently released parent
> version is out of date with regards to the new release setup I have to
> release that as well.
>
> Tags:
> https://svn.apache.org/repos/asf/maven/shared/tags/maven-app-configuration-1.0
>
>
> Staged at:
> http://people.apache.org/~jmcconnell/org/apache/maven/shared/
>
> This would be an initial release of these fairly simple components,
> they are primarily to bring some unity in configuration elements
> between archiva and continuum right now.
>
> Vote is open for 72 hours.
>
> +1
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] maven-dependency-plugin 2.0-alpha-4 AND maven-dependency-analyzer 1.0-alpha-2

[Joakim Erdfelt]

+1

- Joakim

Brian E. Fox wrote:

I'd like to release maven-dependency-plugin:2.0-alpha-4 and the shared
maven-dependency-analyzer 1.0-alpha-2 that it depends on.

Tags:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-dependency-plug
in-2.0-alpha-4/
http://svn.apache.org/repos/asf/maven/shared/tags/maven-dependency-analy
zer-1.0-alpha-2/

Staged at:
http://people.apache.org/~brianf/staging-repository

Changes:
Fixed several issues related to the new analyze and analyze-dep-mgt
goals:

Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-4

** Bug
* [MDEP-72] - "IllegalArgumentException: Cannot accept visitor on
URL" when project contains a non-jar (e.g. zip) dependency
* [MDEP-73] - dependency:analyze in a packaging=pom project should
skip, not die or produce a redundant report
* [MDEP-74] - dependencies in test scope are not handled properly by
analyze
* [MDEP-77] - dependency:analyze is reporting impossible results
* [MDEP-78] - analyze-dep-mgt has the labels reversed
* [MDEP-79] - index out of bounds exception on analyze against
maven-war-plugin

** Improvement
* [MDEP-76] - It would be nice to analyze dependencyManagement
exclusions as well as versions


Vote is open for 72 hours.

+1

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

[WIKI] Archiva Roadmap & Design

[Joakim Erdfelt]

Just a quick note to other Archiva Developers that the Product Roadmap
and Design docs are being updated on wiki (Confluence)

The Roadmap::
http://docs.codehaus.org/display/MAVENUSER/Archiva+Roadmap

I think we might need to split up the roadmap to 1.0-alpha, 1.0-beta,
1.0-rc, and finally 1.0. WDYT?

The Design Docs::
http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva

As usual, these documents are ongoing and fluid.

Comments are appreciated.

- Joakim

Re: [vote] Commit privs for Ralph Goers

[Joakim Erdfelt]

+1

- Joakim

Jason van Zyl wrote:
> Hi,
>
> As part of the massive overhaul that was MNG-1577 I wanted to also to
> ask for commit privs for Ralph. Much of my recent work has been with
> Patrick on getting MNG-1577 into the codebase, but Ralph also did a
> great deal of work and when looking at the last patch I committed to
> the documentation it reminded me of the initial conversation I had
> with Ralph at ApacheCon when he offered the first version of the
> patch. Again, this was not a trivial patch and though I don't
> typically ask for commit privs based on a patch this was a long drawn
> out effort that required a lot of work and is exceptional. Ralph is a
> committer on Cocoon and think he would make a fine committer here.
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> -
> 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] Commit Privs for Patrick Schneider

[Joakim Erdfelt]

+1

- Joakim

Jason van Zyl wrote:
> Hi,
>
> Patrick has, for at least a couple months, been working on MNG-1577,
> has written extensive tests, changed and altered patches for anything
> and everything that's been asked of him. He worked with Mike and Ralph
> discussing the problem, getting  the patches prepared and in for this
> fix, ultimately arriving at a solution that makes Maven a far more
> reliable system. He's been great to work with and he never relented
> and patched and patched and patched. He is now intimately familiar
> with Maven's dependency mechanism and he would be a great addition to
> the team in helping us sort out more artifact related problems :-)
>
> +1
>
> Thanks,
>
> Jason.
>
>
>
> -
> 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] maven-remote-resources-plugin 1.0-alpha-4

[Joakim Erdfelt]

+1

- Joakim

Daniel Kulp wrote:
> Following the "release often" mantra...  :-(
>
>
> Several projects have hit "Critical" bugs that is causing builds to fail 
> when using the remote-resources plugin.1.0-alpha-4 contains no new 
> functionality.  It just fixes the two critical bugs.
>
>
> Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-4
>
> ** Bug
> * [MRRESOURCES-14] - Running the process goal fails if there is no 
> target directory
> * [MRRESOURCES-15] - ClassCast Exception happens when depending on 
> the snapshot artifacts
>
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: incubator m2 repository

[Joakim Erdfelt]

One question I have ...

Do you want to identify the incubating projects on central in any way?
A groupId prefix of org.apache.incubating.* for example?

- Joakim

Daniel Kulp wrote:
> Just to let everyone know, there is a long thread about the incubator M2 
> repository on general@incubator.apache.org:
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/200703.mbox/<31cc37360703140920h6a601b57gbb86ff0cd5e8049b%40mail.gmail.com>
>
> Since this affects Maven users as well as projects like NMaven, it would 
> be good to get other peoples input, especially those that run the 
> central repository.
>
> The other complication will be if they decide to remove it, we'll have to 
> merge it into the ibiblio sync respository.   Are the tools ready for 
> that?
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wagon & Components/trunk

[Joakim Erdfelt]

Just a little update before going to bed ...
Jason has been having some problems with the bleeding edge wagon
(1.0-beta-3-SNAPSHOT) on components/trunk.

We are in the process of rolling back to 1.0-beta-2 (with bug fixes) on
components/trunk.

Here's the end svn state we are working on...

Wagon 2.0-SNAPSHOT Development is on:
   https://svn.apache.org/repos/asf/maven/wagon/trunk/

Wagon 1.0-rc1-SNAPSHOT is on:
   https://svn.apache.org/repos/asf/maven/wagon/branches/wagon-1.x/

Maven components using Wagon 2.0-SNAPSHOT is on:
  
https://svn.apache.org/repos/asf/maven/components/branches/maven-wagon-ng/

"Please make a note of it."

I will take the maven components/trunk and have it's
maven-artifact-manager reverted to use wagon 1.0-rc1-SNAPSHOT in the
morning (or sooner if Jason decides to fix it before I get a chance to)

- Joakim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Trying to use standard versioning

[Joakim Erdfelt]

+1

- Joakim

Jason van Zyl wrote:
> Hi,
>
> The impetus for this is wanting to release the surefire plugin that
> has a tiny bug in it. We are versioning our Maven release
> major.minor.micro so why don't we do the same with our plugin and
> treat everything like we're going to do small incremental releases
> like we should be doing. I would like to change all the versions on
> plugin to follow the major.minor.micro format starting with the
> surefire plugin.
>
> Thanks,
>
> Jason.
>
>
>
> -
> 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] Apache parent pom 4

[Joakim Erdfelt]

+1

- Joakim

Carlos Sanchez wrote:
> anything pending to do in the apache pom? there are some mistakes in
> the version 3 like organization name that propagates to all apache
> projects.
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r511667 - /maven/continuum/trunk/continuum-rpc-client/pom.xml

[Joakim Erdfelt]

You have a few options here.

1) Don't expose jpox enhanced objects in the rpc interface.
2) Have a second set of identical objects, on a different package, that
are exposed via RPC. This would require a set of Copy methods to copy
the JPOX enhanced object values into this second set of objects.
3) Don't use jpox.  Use ibatis instead.

Short answer, you can't use jpox and rpc at the same time, on the same
objects.

I have this same problem with archiva, and my desire to use the Maven
Model and Metadata objects in a DB mapping.  I can't enhance those
objects, so I choose ibatis instead.

- Joakim


Andrew Williams wrote:
> Reverted. Can someone look at fixing this the correct way then? I
> would like to use this code.
>
> Andy
>
> On 26 Feb 2007, at 12:53, Emmanuel Venisse wrote:
>
>> This patch isn't correct because the rpc client doesn't need enhanced
>> classes.
>> We need to generate model classes for the rpc client without
>> enhancement.
>> Please, revert your patch.
>>
>> Emmanuel
>>
>> Andrew Williams a écrit :
>>> The SampleClient fails to run without it.
>>> Caused by: java.lang.NoClassDefFoundError:
>>> javax/jdo/spi/PersistenceCapable
>>> at java.lang.ClassLoader.defineClass0(Native Method)
>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
>>> at
>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
>>> at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>>> at
>>> org.codehaus.mojo.exec.ExecJavaMojo$IsolatedClassLoader.loadClass(ExecJavaMojo.java:265)
>>> 
>>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>>> at
>>> org.apache.maven.continuum.rpc.ProjectsReader.readProjects(ProjectsReader.java:79)
>>> 
>>> at
>>> org.apache.maven.continuum.rpc.SampleClient.main(SampleClient.java:51)
>>> ... 23 more
>>> A
>>> On 26 Feb 2007, at 08:49, Emmanuel Venisse wrote:
 Why? we don't use it in the rpc client.

 [EMAIL PROTECTED] a écrit :
> Author: handyande
> Date: Sun Feb 25 16:07:34 2007
> New Revision: 511667
> URL: http://svn.apache.org/viewvc?view=rev&rev=511667
> Log:
> rpc client need jdo2 too
> Modified:
> maven/continuum/trunk/continuum-rpc-client/pom.xml
> Modified: maven/continuum/trunk/continuum-rpc-client/pom.xml
> URL:
> http://svn.apache.org/viewvc/maven/continuum/trunk/continuum-rpc-client/pom.xml?view=diff&rev=511667&r1=511666&r2=511667
>
> ==
>
> --- maven/continuum/trunk/continuum-rpc-client/pom.xml (original)
> +++ maven/continuum/trunk/continuum-rpc-client/pom.xml Sun Feb 25
> 16:07:34 2007
> @@ -70,5 +70,9 @@
>commons-httpclient
>2.0.2
>  
> +
> +  org.codehaus.plexus
> +  plexus-jdo2
> +
>
>  

>>
>

Re: Maven banner?

[Joakim Erdfelt]

The banner is useful in debugging.
Especially the versions of non-project dependencies ( maven / wagon /
plugins )

Having a banner would address some of that.

Having an 'opt-out' of the banner would also be useful (ala the
  and  type settings in the
$HOME/.m2/settings.xml)

I agree with Jason about the level of noise.  The logging has to be
addressed first.

- Joakim

Brian E. Fox wrote:
> Yes we get enough junk in the logs, please don't put that in. If you
> don't know you're running maven when you type mvn, then there's no hope
> for you. If you want to know the version from logs, then it should be
> simple to just output a simple version line (1 line!!!) in the
> execution. 
>
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Monday, February 26, 2007 8:30 AM
> To: Maven Developers List
> Subject: Re: Maven banner?
>
>
> On 26 Feb 07, at 7:55 AM 26 Feb 07, Andrew Williams wrote:
>
>   
>> I must admit I was very tempted to put that back in.
>> Perhaps not exactly the same logo, make a change in the 2.1 tree :)
>>
>> I wondered also if I could tie it to some colour logging work I have 
>> up my sleeve so we could colour the "a" of Maven like the official 
>> logo.
>>
>> Any objections?
>>
>> 
>
> I think the logging needs to be overhauled first so that it can be
> turned off easily and changed from the embedder. Toning down all the
> noise might be a good idea too before we subject people color. If the
> color is used effectively I think it could be a nice addition though.  
> I do think we need to ramp down the noise first.
>
> Jason.
>
>   
>> Andy
>>
>> On 15 Feb 2007, at 04:05, Jason Dillon wrote:
>>
>> 
>>> What happened to the banner when executing Maven?  I'm glad its not 
>>> there by default, but I'd like to turn it on for remote builds so 
>>> that my logs capture what version of Maven was used.
>>>
>>> Maybe a '--banner' flag or something?  Or maybe a new goal on the 
>>> help plugin, to show maven version, and some settings like os and 
>>> java version fluff?
>>>
>>> --jason
>>>
>>> -
>>> 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]
>>
>>
>> 
>
>
> -
> 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]
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Planning at EclipseCon

[Joakim Erdfelt]

(replies inline below)

- Joakim

Jason van Zyl wrote:
> Hi,
>
> I think at least a few of us will be at EclipseCon. Brett, you
> mentioned that you're going to be there and I see that Carlos is going
> to be there.
>
> I would like to take a swing at the planning for Maven 2.1 in a more
> official way then JIRA and Maven Enterprise. I have chatted with
> Kenney and John about 2.1 work but it needs to be placed in the wiki
> for broad consumption. I will clean up the design queue, the wiki and
> related JIRA issues which are all a mess. I will attempt to finish
> this for EclipseCon and I'm going to try using the pattern approach to
> changes and I can do a little presentation on the method at
> EclipseCon. I will also talk with Andy and try to get the ideas for
> Maven Enterprise which is in the sandbox but we would like to get a
> first working version based on official releases and then put up the
> vote to move it out of the sandbox.
Excellent news!  If we have some ideas we want to throw on the table,
but can't be there in person, what's the best way for us to get them to you?
> I know Joakim has been doing a lot of work on Wagon and Archiva so are
> you going to be at EclipseCon? If you have a way you want to
> communicate changes. I honestly didn't find the large email
> particularly compelling and anyone not on the list will never find it.
> I honestly think the design documents approach in the wiki is the only
> way.
I'm working on getting a grip on some of the design (reporting) still. 
I'll be spending substantial quantities of time in the wiki this week
updating the archiva docs with the updates / plans / milestones / future.

As for Wagon, I'm not aware of a location in Wiki for that.   ( /me
looks deeply into jira's eyes ... )
> http://docs.codehaus.org/display/MAVEN/EclipseCon+2007+Maven+BOF
Oh, I guess this is the answer to my first question. heh.
>
> Jason.
>
> -
> 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: Extension to install custom proxy muck in Maven?

[Joakim Erdfelt]

Actually, I believe the current maven 2.0.5 supports setting up a
 entry like this 


  corporate.proxy
  *
  http://my.corporate.proxy/maven/


(typed from memory, parsing errors potential in effect)

This would in effect send all requests to your corporate proxy.

- Joakim

Jason Dillon wrote:
> (seems I keep sending these to [EMAIL PROTECTED] instead of [EMAIL PROTECTED])
>
> Is it possible to install a Maven extension which can configure
> Maven's proxy handling?
>
> I'm wondering if with little work, that it might be possible to create
> some kinda of plugin to Maven, which would embed a simply proxy server
> (kinda like DSMP) directly into Maven, and then configure Maven to use
> that server as a proxy.
>
> I really need a way to control what repos our projects use, and since
> we use artifacts which list other repos, there is no easy way (that I
> know of) to limit this behavior except for configuring a proxy and
> putting the controls in the proxy process.
>
> The problem with this technique is that it...
>
> a) requires users' to configure maven to use the proxy
>
> b) requires users to start a proxy process and/or point at a remote
> server, in which case you need a remote server and bandwidth to
> effectively use.
>
> Both of these end up becoming blockers to actually making this a
> reality.  But, Maven is a Plexus application, and its easy enough to
> write a Plexus component which implements this proxy, so why not have
> the one Maven process boot up the proxy, and then configure Maven to
> use that proxy?  This seems to me the best way, short of major changes
> to Maven, to get real concrete control over how Maven uses remote
> repositories.
>
> For the case at hand, what I really want is to, no matter what repos
> are configured (by the project or by dependencies of the project),
> only grab artifacts from one repository... and to help
> populate/maintain that repository, flip a switch on the proxy
> component to all it to pass-through to all configure urls for artifacts.
>
> There are a few other use cases I can think of... I'd like to install
> a listener into the proxy component which will simply catalog all
> artifact requests and at the end of a build simply dump a list of all
> artifacts which were used.  Another, is that for some automated
> builds, I need to keep the "cache" of artifacts separate from the set
> of artifacts which are actually used by a project.  This isn't' really
> possible now, but with a proxy layer, I can easily separate cached
> artifacts from artifacts used in a project.
>
>  * * *
>
> Anyways... I really think that having this extra proxy component in
> the Maven process would be a massive help to solve some of the more
> complicated repository issues which we (Geronimo) are facing with
> using Maven.  I think that if I could get a proxy component into the
> Maven bootstrap, and provide some ability for the project to configure
> it, that it would really help improve the quality of our builds with
> Maven.
>
> I also don't think its that difficult to implement... the major issue
> is... how does one install such a bootstrap component into Maven?  Is
> it possible?  Or does one need to provide a separate assembly with
> extra libs and extra components.xml or something along those lines?
>
> --jason
>
>
> -
> 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] merge Archiva MRM-239 branch to trunk

[Joakim Erdfelt]

With the following voters in favor ...

  Brett, Arnaud, Emmanuel, Nicolas

... the merge will commence shortly

- Joakim


Brett Porter wrote:
> +1
>
> I'm not done, but I can't see any issues at a high level. I'll post
> any thoughts I have later.
>
> - Brett
>
> On 23/02/2007, at 7:54 PM, Brett Porter wrote:
>
>> Applying them now won't help... they'd still need to painstakingly be
>> applied to the branch. Just as easy to do that after the merge (if
>> they are still relevant).
>>
>> I believe some things on trunk may have changed since the last merge
>> - a final check of that will be needed first.
>>
>> I'm still reviewing the code, myself... vote to arrive later tonight :)
>>
>> - Brett
>>
>> On 23/02/2007, at 7:49 PM, Arnaud HERITIER wrote:
>>
>>> One thing before ...
>>> Can we have the list of patchs that aren't yet applied on the trunk ?
>>> Don't we have to apply them before or we'll never be able to do it
>>> (due to
>>> the important changes you made) ?
>>>
>>> Arnaud
>>>
>>> On 2/23/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
>>>>
>>>> +1
>>>>
>>>> Emmanuel
>>>>
>>>> Joakim Erdfelt a écrit :
>>>> > I would like to merge the archiva-MRM-239 branch back to trunk.
>>>> >
>>>> > Not sure how long I should wait for the vote replies, but I'll do
>>>> the
>>>> > usual 72.
>>>> >
>>>> > - Joakim
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>

Re: [vote] Release Maven Surefire 2.3

[Joakim Erdfelt]

+1

- Joakim

Brett Porter wrote:
> Please vote for the release of Surefire 2.3. This now includes the
> API, providers, plugin and report plugin.
>
> [ ] +1
> [ ] 0
> [ ] -1
>
> Staged at: http://people.apache.org/~brett/release-staging-repo/
>
> Vote is open for 72 hours.
>
> Release notes:
>
> ** Bug
> * [SUREFIRE-49] - Surefire leaves null/$TestNGGroupName
> directories after mvn test
> * [SUREFIRE-53] - context classloader not always reset to original
> values
> * [SUREFIRE-54] - Remove use of parent classloader in
> surefirebooter but keep TestNG support working
> * [SUREFIRE-99] - Surefire plugin fails if JUnit is not available
> * [SUREFIRE-101] - Plugin not longer sets system properties when
> forking is on and debugging information is not correct
> * [SUREFIRE-105] - Documentation link on website does not point to
> surefire parameter docs
> * [SUREFIRE-106] - Classloading problem for getting a resource
> * [SUREFIRE-113] - surefire-providers-2.0.pom contains strange
> dependencies which generate error
> * [SUREFIRE-114] - Surefire plugin throws NoSuchMethodException
> when errors occur during TestSetup decorator
> * [SUREFIRE-120] - When you  a JUnit TestSuite (with no
> test methods), no tests are run
> * [SUREFIRE-122] - With forkmode once, XML reports are cumulative
> * [SUREFIRE-123] - SurefireBooter can initialize classloader with
> badly formed URLs
> * [SUREFIRE-125] - Surefire finds test classes but ignores test
> methods and configuration methods with TestNG and includes tag
> * [SUREFIRE-127] - Wrong issue-site URL on website
> * [SUREFIRE-263] - Source repository information on the web site
> is out of date
>
> ** Improvement
> * [SUREFIRE-31] - support junit 4.0
> * [SUREFIRE-134] - Display location of test failures/errors on
> summary
> * [SUREFIRE-135] - when fork is enabled, Surefire should use the
> same JVM running Maven (i.e. use java.home sysprop), rather than
> expecting java to be in the system PATH
> * [SUREFIRE-138] - Add option to redirect stdout from tests to a file
>
> ** New Feature
> * [SUREFIRE-129] - add a property to skip tests execution (but not
> tests compilation)
>
> ** Task
> * [SUREFIRE-133] - Review Plugin Documentation
>
> Note: a 2.4 release is being worked on immediately to resolve some
> issues with TestNG. This release is being made available to users
> having the above problems before that work begins.
>
> Cheers,
> Brett
>
>
> -
> 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: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT

[Joakim Erdfelt]

Just some thoughts.

I would like to change wagon-webdav's protocol definition.

Currently it is "dav:http://"; and "dav:https://"; both of which are
technically invalid protocols.
It should be "dav://" and "davs://".

I've wanted to make the wagon's register URL handlers for themselves too.
That would allow for a more natural Streaming Wagon implementation too.

- Joakim

Joakim Erdfelt wrote:
> The changes to wagon are ... (just to make sure they show in john's
> gmail account)
>
> 1) Timeouts
> 2) Streaming Wagon
> 3) Limited Transactions
>
> - Joakim
>
> John Casey wrote:
>   
>> Hi all,
>>
>> I have something to point out that I think the entire Maven development
>> community needs to hear. I've been doing a lot of work recently with
>> Maven
>> trunk, so I notice any (perhaps inevitable) instability that comes
>> down the
>> pike from dependency APIs. Recently, I've been having a LOT of trouble in
>> this area.
>>
>> Particularly in the Wagon API. It seems that a change was rolled into
>> wagon-provider-api around the beginning of February that introduced
>> some new
>> methods into the Wagon interface. This is not in itself a problem, even
>> though the current code version is at 1.0-*beta*-3-SNAPSHOT. What
>> causes an
>> issue is the fact that these new methods are then assumed to be in
>> place by
>> the new DefaultWagonManager, effectively breaking that manager's backward
>> compatibility with previous releases of Wagon providers.
>>
>> I tracked all of this down over the course of the past few days, in
>> between
>> doing the things that I'm actually focused on doing. I can fix this one
>> problem by myself; I'm not pleading for help here. However, I cannot
>> act as
>> the gatekeeper for all APIs that get used in Maven trunk, to ensure their
>> stability and backward compatibility. I've been informed that there
>> are many
>> other such changes heading for Wagon...interestingly enough, a quick
>> search
>> of my GMail account doesn't turn up any discussion of these changes
>> (unless
>> it's buried in the deep past somewhere).
>>
>> I know that this email can look a bit hypocritical on its face, but I
>> really
>> do feel that we owe it to our user base to be a little more proactive in
>> ensuring backward compatibility than we have in the past. I understand
>> that
>> many Maven developers are on various deadlines, but those deadlines do
>> not
>> originate in the Maven ASF project, and shouldn't cause undue harm to the
>> community or its code. I'm not trying to say we need to rigidly adopt and
>> conform to some process or other, but we each individually need to take
>> responsibility for discussing and testing any major changes we plan to
>> put
>> into Maven or its dependencies.
>>
>> IMHO, pushing new features into a beta API is irresponsible unless you
>> can
>> be ABSOLUTELY certain it will not impact backward compatibility. In these
>> cases, it is my understanding that the normal practice is to create a
>> final
>> release of the existing API, and then push these bigger changes into the
>> next version.
>>
>> If there's even a shadow of doubt about what effect a change will have on
>> the user community, we need to make a serious effort to start a
>> discussion
>> about it on this list.
>>
>>
>> Regards,
>>
>> John
>>
>> 
>
>
> -
> 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: Separating out the conversion tools

[Joakim Erdfelt]

Done.

https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction/
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-artifact-converter/

Though I haven't moved them out of Archiva yet.
Waiting to get authorization to merge the branch back into trunk first.

- Joakim

Jason van Zyl wrote:
>
> On 22 Feb 07, at 10:12 AM 22 Feb 07, Joakim Erdfelt wrote:
>
>> I have plans to make that entire stack isolated and unaffected by
>> reporting / dao / web / indexing / etc...
>> As well as making an import applet utilize the conversion routines too
>> (want this to be lightweight too).
>>
>
> Good, then let's move it out of archiva.
>

Re: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT

[Joakim Erdfelt]

The Wagon.getProtocol() method could probably be dropped.
But that won't address the bigger concern.   Backwards compatibility.

- Joakim

John Casey wrote:
> Also, to be clear, in the past I've broken things massively in Maven and
> other places. Almost without fail, someone has tracked me down, and
> waited
> while I stopped everything I was doing, and fixed the problem...with
> tests,
> if possible.
>
> On 2/22/07, John Casey <[EMAIL PROTECTED]> wrote:
>>
>> Just to be clear - did I miss a volley of emails on these topics?
>>
>> -j
>>
>> On 2/22/07, Joakim Erdfelt <[EMAIL PROTECTED] > wrote:
>> >
>> > The changes to wagon are ... (just to make sure they show in john's
>> > gmail account)
>> >
>> > 1) Timeouts
>> > 2) Streaming Wagon
>> > 3) Limited Transactions
>> >
>> > - Joakim
>> >
>> > John Casey wrote:
>> > > Hi all,
>> > >
>> > > I have something to point out that I think the entire Maven
>> > development
>> > > community needs to hear. I've been doing a lot of work recently with
>> > > Maven
>> > > trunk, so I notice any (perhaps inevitable) instability that comes
>> > > down the
>> > > pike from dependency APIs. Recently, I've been having a LOT of
>> trouble
>> > in
>> > > this area.
>> > >
>> > > Particularly in the Wagon API. It seems that a change was rolled
>> into
>> > > wagon-provider-api around the beginning of February that introduced
>> > > some new
>> > > methods into the Wagon interface. This is not in itself a problem,
>> > even
>> > > though the current code version is at 1.0-*beta*-3-SNAPSHOT. What
>> > > causes an
>> > > issue is the fact that these new methods are then assumed to be in
>> > > place by
>> > > the new DefaultWagonManager, effectively breaking that manager's
>> > backward
>> > > compatibility with previous releases of Wagon providers.
>> > >
>> > > I tracked all of this down over the course of the past few days, in
>> > > between
>> > > doing the things that I'm actually focused on doing. I can fix this
>> > one
>> > > problem by myself; I'm not pleading for help here. However, I cannot
>> > > act as
>> > > the gatekeeper for all APIs that get used in Maven trunk, to ensure
>> > their
>> > > stability and backward compatibility. I've been informed that there
>> > > are many
>> > > other such changes heading for Wagon...interestingly enough, a quick
>> > > search
>> > > of my GMail account doesn't turn up any discussion of these changes
>> > > (unless
>> > > it's buried in the deep past somewhere).
>> > >
>> > > I know that this email can look a bit hypocritical on its face,
>> but I
>> > > really
>> > > do feel that we owe it to our user base to be a little more
>> proactive
>> > in
>> > > ensuring backward compatibility than we have in the past. I
>> understand
>> >
>> > > that
>> > > many Maven developers are on various deadlines, but those
>> deadlines do
>> > > not
>> > > originate in the Maven ASF project, and shouldn't cause undue
>> harm to
>> > the
>> > > community or its code. I'm not trying to say we need to rigidly
>> adopt
>> > and
>> > > conform to some process or other, but we each individually need to
>> > take
>> > > responsibility for discussing and testing any major changes we
>> plan to
>> > > put
>> > > into Maven or its dependencies.
>> > >
>> > > IMHO, pushing new features into a beta API is irresponsible
>> unless you
>> > > can
>> > > be ABSOLUTELY certain it will not impact backward compatibility. In
>> > these
>> > > cases, it is my understanding that the normal practice is to
>> create a
>> > > final
>> > > release of the existing API, and then push these bigger changes into
>> > the
>> > > next version.
>> > >
>> > > If there's even a shadow of doubt about what effect a change will
>> have
>> > on
>> > > the user community, we need to make a serious effort to start a
>> > > discussion
>> > > about it on this list.
>> > >
>> > >
>> > > Regards,
>> > >
>> > > John
>> > >
>> >
>> >
>> > -
>> > 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: Broken backward compatibility in Wagon 1.0-beta-3-SNAPSHOT

[Joakim Erdfelt]

The changes to wagon are ... (just to make sure they show in john's
gmail account)

1) Timeouts
2) Streaming Wagon
3) Limited Transactions

- Joakim

John Casey wrote:
> Hi all,
>
> I have something to point out that I think the entire Maven development
> community needs to hear. I've been doing a lot of work recently with
> Maven
> trunk, so I notice any (perhaps inevitable) instability that comes
> down the
> pike from dependency APIs. Recently, I've been having a LOT of trouble in
> this area.
>
> Particularly in the Wagon API. It seems that a change was rolled into
> wagon-provider-api around the beginning of February that introduced
> some new
> methods into the Wagon interface. This is not in itself a problem, even
> though the current code version is at 1.0-*beta*-3-SNAPSHOT. What
> causes an
> issue is the fact that these new methods are then assumed to be in
> place by
> the new DefaultWagonManager, effectively breaking that manager's backward
> compatibility with previous releases of Wagon providers.
>
> I tracked all of this down over the course of the past few days, in
> between
> doing the things that I'm actually focused on doing. I can fix this one
> problem by myself; I'm not pleading for help here. However, I cannot
> act as
> the gatekeeper for all APIs that get used in Maven trunk, to ensure their
> stability and backward compatibility. I've been informed that there
> are many
> other such changes heading for Wagon...interestingly enough, a quick
> search
> of my GMail account doesn't turn up any discussion of these changes
> (unless
> it's buried in the deep past somewhere).
>
> I know that this email can look a bit hypocritical on its face, but I
> really
> do feel that we owe it to our user base to be a little more proactive in
> ensuring backward compatibility than we have in the past. I understand
> that
> many Maven developers are on various deadlines, but those deadlines do
> not
> originate in the Maven ASF project, and shouldn't cause undue harm to the
> community or its code. I'm not trying to say we need to rigidly adopt and
> conform to some process or other, but we each individually need to take
> responsibility for discussing and testing any major changes we plan to
> put
> into Maven or its dependencies.
>
> IMHO, pushing new features into a beta API is irresponsible unless you
> can
> be ABSOLUTELY certain it will not impact backward compatibility. In these
> cases, it is my understanding that the normal practice is to create a
> final
> release of the existing API, and then push these bigger changes into the
> next version.
>
> If there's even a shadow of doubt about what effect a change will have on
> the user community, we need to make a serious effort to start a
> discussion
> about it on this list.
>
>
> Regards,
>
> John
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Control of maven using prerequisites

[Joakim Erdfelt]

Plugins can not be removed from the build.
However configuration portions can be overridden.

If you have checks that must always run, hardcode it.
Or use a resource from an URL or artifact to get the values.
Just don't let someone use the plugin configuration to change the value.

- Joakim

Brian E. Fox wrote:
> Actually I was talking about specifying other plugin/dependency plugins
> to be enforced but I see your point. How would we make it not possible
> to override in a child? Using a static value to store previously entered
> config?
>
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 14, 2007 10:37 PM
> To: Maven Developers List
> Subject: Re: Control of maven using prerequisites
>
>
> On 14 Feb 07, at 10:28 PM 14 Feb 07, Brian E. Fox wrote:
>
>   
>> So the initial feature list for the "maven-enforcer-plugin" is:
>> OS, Maven Rev, Jdk Rev. Anything else that might be usefull from a
>> Configuration Management standpoint? Most other things can already be
>> controlled via pluginManagement/dependencyManagement...although it
>> doesn't stop someone from overriding at a local pom level.
>>
>> 
>
> Maybe this is a new flavor of plugin that can't be reconfigured or  
> have any other configurations merged. Not sure if you could  
> categorically state you want X, Y, and Z for your entire system but  
> programmatically we could effectively make it impossible to change.
>
> Jason.
>
>   
>> -Original Message-
>> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, February 14, 2007 9:56 PM
>> To: Maven Developers List
>> Subject: Re: Control of maven using prerequisites
>>
>>
>> On 14 Feb 07, at 8:42 PM 14 Feb 07, Brian E. Fox wrote:
>>
>> 
>>> Now that 2.0.5 is out and more frequent releases are expected, I  
>>> think
>>> that http://jira.codehaus.org/browse/MNG-2423 is even more important.
>>> Currently the prerequisites value is not inherited and thus we
>>> can't use
>>> it in a company "super-pom" to enforce a minimum Maven version. My
>>> workaround is to create an empty plugin that has a prereq and include
>>> that in the super-pom. This seems kludgey an kind of unnecessary  
>>> since
>>> there is a field in the pom to do this...it just only applies if
>>> defined
>>> in each child pom or when building from a reactor that contains  
>>> it. Is
>>> there any chance this can get bumped to 2.0.6? I'm willing to try and
>>> submit a patch I could get a pointer where to look.
>>>
>>>   
>> The prereq is specifically for plugins, or other tools, that need a
>> specific version of Maven. It was not meant as a means of enforcement
>> for your development environment. Trying to mix these concerns would
>> cause problems.
>>
>> I think what you need is a plugin that runs in the validate phase
>> (call it the Enforcer Plugins :-) that checks things like jdk
>> version, mvn version, operating system or whatever else you might
>> want. Configure this in your parent POM and then you're all set.
>>
>> Jason.
>>
>> 
>>> Thanks,
>>>
>>> Brian
>>>
>>>   
>> -
>> 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]
>>
>>
>> 
>
>
> -
> 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]
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Control of maven using prerequisites

[Joakim Erdfelt]

Check out the geronimo tools-maven-plugin
Found at
http://svn.apache.org/repos/asf/geronimo/genesis/trunk/plugins/tools-maven-plugin/

It is used by the current geronimo for enforcing various minimum aspects
of the build environment.

Example: (from
http://svn.apache.org/repos/asf/geronimo/daytrader/trunk/pom.xml )


org.apache.geronimo.genesis.plugins
tools-maven-plugin


validate-java-version
validate

require-java-version


1.5*






Enjoy

- Joakim


Brian E. Fox wrote:
> So the initial feature list for the "maven-enforcer-plugin" is:
> OS, Maven Rev, Jdk Rev. Anything else that might be usefull from a
> Configuration Management standpoint? Most other things can already be
> controlled via pluginManagement/dependencyManagement...although it
> doesn't stop someone from overriding at a local pom level.  
>
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, February 14, 2007 9:56 PM
> To: Maven Developers List
> Subject: Re: Control of maven using prerequisites
>
>
> On 14 Feb 07, at 8:42 PM 14 Feb 07, Brian E. Fox wrote:
>
>   
>> Now that 2.0.5 is out and more frequent releases are expected, I think
>> that http://jira.codehaus.org/browse/MNG-2423 is even more important.
>> Currently the prerequisites value is not inherited and thus we  
>> can't use
>> it in a company "super-pom" to enforce a minimum Maven version. My
>> workaround is to create an empty plugin that has a prereq and include
>> that in the super-pom. This seems kludgey an kind of unnecessary since
>> there is a field in the pom to do this...it just only applies if  
>> defined
>> in each child pom or when building from a reactor that contains it. Is
>> there any chance this can get bumped to 2.0.6? I'm willing to try and
>> submit a patch I could get a pointer where to look.
>>
>> 
>
> The prereq is specifically for plugins, or other tools, that need a  
> specific version of Maven. It was not meant as a means of enforcement  
> for your development environment. Trying to mix these concerns would  
> cause problems.
>
> I think what you need is a plugin that runs in the validate phase  
> (call it the Enforcer Plugins :-) that checks things like jdk  
> version, mvn version, operating system or whatever else you might  
> want. Configure this in your parent POM and then you're all set.
>
> Jason.
>
>   
>> Thanks,
>>
>> Brian
>>
>> 
>
>
> -
> 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]
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]