Re: SVN checkout/update fails

[Joakim Erdfelt]

I agree.

I think we can flatten some of the structure.

We keep this top level structure that brett came up with.
trunk
trunk/archiva-cli
trunk/archiva-docs
trunk/archiva-jetty
trunk/archiva-modules

Move the following structures around ...
trunk/archiva-modules/archiva-base/archiva-consumers/* --> 
trunk/archiva-modules/

trunk/archiva-modules/archiva-base/*  --> trunk/archiva-modules/
trunk/archiva-modules/archiva-reporting/* --> trunk/archiva-modules/
trunk/archiva-modules/archiva-web/* --> trunk/archiva-module/

Basically, there is no project deeper than trunk/archiva-modules/${project}

wdyt?

- Joakim


Rahul Thakur wrote:

Hi,

SVN update for maven-archiva fails on the XP. Joakim kindly looked at 
the SVN error log (attached below) and noted that the path exceeded 
the length imposed by Windows.


Can we please review the modules/packages so people can continue 
checkouts on Windows?


Thanks,

Rahul



C:\oss\maven-archiva>svn up svn: Your .svn/tmp directory may be 
missing or corrupt; run 'svn cleanup' and try again svn: Can't open 
file 
'archiva-modules\archiva-base\archiva-repository-layer\src\test\repositories\metadata-repository\or 
g\apache\archiva\metadata\tests\snap_shots_a\1.0-alpha-11-SNAPSHOT\.svn\tmp\text-base\snap_shots_a-1.0-alpha-11-20070302 
..212723-3.war.svn-base': The system cannot find the path specified.

Re: [vote] Make James William Dumay a committer.

[Joakim Erdfelt]

Just wanted Maria to know that I'm blind and can't read. ;-)
Sorry.

- Joakim

Joakim Erdfelt wrote:

Looks like Brett started a trend.

Consider this the vote thread now.

I'll either wait till Tuesday, April 22nd to tabulate the votes, or 
wait till all of the PMCs vote (which is a real possibility).


So far, we have +1 votes from the following people.

+1 Brett Porter
+1 Fabrice Bellingard
+1 Nicolas de Loof
+1 Arnaud Heritier
+1 Joakim Erdfelt

Which leaves the following PMCs to vote. (sorry Wendy and Maria, your 
comments, while positive, are not really a vote)


[ ] Wendy Smoak
[ ] Maria Odea Ching
[ ] Dennis Lundberg
[ ] Jesse McConnell
[ ] Edwin Punzalan
[ ] Carlos Sanchez
[ ] John Tolentino
[ ] Emmanuel Venisse

If we all remind the other PMCs to vote, we can get this vote 
finalized sooner.

Thanks for your time.

- Joakim

Brett Porter wrote:

Can I just vote now? :)

+1

On 16/04/2008, at 8:45 AM, Joakim Erdfelt wrote:

Now I realize this isn't the normal process, and heck, we (the 
archiva pmc) haven't even established our own process for this.
This will be a public discussion, not on the pmc list (as ... well 
... the pmc list doesn't exist. yet)


I've asked James on irc (he's nick i386 on #archiva btw) if it would 
be ok to discuss this in public. He stated that it's fine with him, 
he just asks that any criticism be constructive.


James has been shown that he is very knowledgable of the Apache 
Archiva project, its source, and its goals.


I would like to nominate him as an Apache Archiva committer.
I'll leave this discussion open for a week, then call a vote if 
everyone agrees.


- Joakim


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

[vote] Make James William Dumay a committer.

[Joakim Erdfelt]

Looks like Brett started a trend.

Consider this the vote thread now.

I'll either wait till Tuesday, April 22nd to tabulate the votes, or wait 
till all of the PMCs vote (which is a real possibility).


So far, we have +1 votes from the following people.

+1 Brett Porter
+1 Fabrice Bellingard
+1 Nicolas de Loof
+1 Arnaud Heritier
+1 Joakim Erdfelt

Which leaves the following PMCs to vote. (sorry Wendy and Maria, your 
comments, while positive, are not really a vote)


[ ] Wendy Smoak
[ ] Maria Odea Ching
[ ] Dennis Lundberg
[ ] Jesse McConnell
[ ] Edwin Punzalan
[ ] Carlos Sanchez
[ ] John Tolentino
[ ] Emmanuel Venisse

If we all remind the other PMCs to vote, we can get this vote finalized 
sooner.

Thanks for your time.

- Joakim

Brett Porter wrote:

Can I just vote now? :)

+1

On 16/04/2008, at 8:45 AM, Joakim Erdfelt wrote:

Now I realize this isn't the normal process, and heck, we (the 
archiva pmc) haven't even established our own process for this.
This will be a public discussion, not on the pmc list (as ... well 
... the pmc list doesn't exist. yet)


I've asked James on irc (he's nick i386 on #archiva btw) if it would 
be ok to discuss this in public. He stated that it's fine with him, 
he just asks that any criticism be constructive.


James has been shown that he is very knowledgable of the Apache 
Archiva project, its source, and its goals.


I would like to nominate him as an Apache Archiva committer.
I'll leave this discussion open for a week, then call a vote if 
everyone agrees.


- Joakim


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Re: [Proposal] Replacing Archiva-webdav with Apache Jackrabbits WebDav Servlet

[Joakim Erdfelt]

James William Dumay wrote:

Hey all,
I've opened MRM-781 which removes the plexus based archiva-webdav module
in favour of a smaller implementation based on Apache Jackrabbits webdav
servlet. This implementation is significantly smaller.

This change will allow us to address MRM-684 without much complexity.

Currently, HTTP GET and PUT work correctly but more work needs to be
done on providing the correct Webdav resource properties needed for a
full webdav implementation (not to mention a lot more unit tests).

It would be excellent if I could get this into a branch soon as the
change set is getting unwieldy.
 
I would appreciate your thoughts and comments.


Thanks
James
  


(I know this has been discussed in irc, just wanted to let everyone else 
know too)


This seems like a pretty big patch/change, do you have a CLA on file at 
apache yet?


- Joakim

Re: [Proposal] Replacing Archiva-webdav with Apache Jackrabbits WebDav Servlet

[Joakim Erdfelt]

James William Dumay wrote:

Hey all,
I've opened MRM-781 which removes the plexus based archiva-webdav module
in favour of a smaller implementation based on Apache Jackrabbits webdav
servlet. This implementation is significantly smaller.

This change will allow us to address MRM-684 without much complexity.

Currently, HTTP GET and PUT work correctly but more work needs to be
done on providing the correct Webdav resource properties needed for a
full webdav implementation (not to mention a lot more unit tests).

It would be excellent if I could get this into a branch soon as the
change set is getting unwieldy.
 
I would appreciate your thoughts and comments.


Thanks
James
  


I'm generally for anything that gets us away from having to maintain our 
own webdav impl.
I'm excited about using another apache product within Archiva, that's 
always a good pro-community aspect of this proposal.


So consider this my +1 for the idea.

- Joakim

[discuss] Make James William Dumay a committer.

[Joakim Erdfelt]

Now I realize this isn't the normal process, and heck, we (the archiva 
pmc) haven't even established our own process for this.
This will be a public discussion, not on the pmc list (as ... well ... 
the pmc list doesn't exist. yet)


I've asked James on irc (he's nick i386 on #archiva btw) if it would be 
ok to discuss this in public. 
He stated that it's fine with him, he just asks that any criticism be 
constructive.


James has been shown that he is very knowledgable of the Apache Archiva 
project, its source, and its goals.


I would like to nominate him as an Apache Archiva committer.
I'll leave this discussion open for a week, then call a vote if everyone 
agrees.


- Joakim

Re: [plexus work] archiva-checksums

[Joakim Erdfelt]

I've made all of the changes.

I'll let it percolate over the next 24 hours (or so) and then integrate 
it into trunk.


- Joakim

Re: [plexus work] archiva-checksums

[Joakim Erdfelt]

Brett Porter wrote:

- I think it can use more tests


Agreed.  Have any special use cases you want fleshed out?


Nah, just coverage for the other classes.


Will do.



- what about passing referenceFile as a final field, since every 
method uses it?


I started ChecksumFile as a utility class, but that might not be the 
best decision.

Any opinions if I make ChecksumFile an instantiated class?

ChecksumFile cf = new ChecksumFile(new File("random.jar"));
if( cf.valid() == false ) {
cf.createChecksum( ChecksumAlgorithm.SHA1 );
}

wdyt?


would that be validateChecksum( ChecksumAlgorithm) ?


Yup. that is more appropriate.
Still, do you see any issue with making the class instantiated vs utility?

- Joakim

Re: [plexus work] archiva-checksums

[Joakim Erdfelt]

Brett Porter wrote:

Looks good to me. I say roll it into trunk.

A couple of uncertainties:
- isn't doFinal required?


doFinal ?


- I think it can use more tests


Agreed.  Have any special use cases you want fleshed out?




Here's some nitpicking that might reduce the amount of code and make 
it clearer:
- rename Hash to ChecksumAlgorithm (might as well be consistent and 
use checksum everywhere instead of alternating through Hash, Digest, 
Checksum?)

- likewise Hasher -> Checksum


Name changes make sense, I'll make these changes this weekend.

- there some duplicated code in isValidChecksums and fixChecksums that 
can be factored out


Good catch, I'll put that on my todo's too.

- what about passing referenceFile as a final field, since every 
method uses it?


I started ChecksumFile as a utility class, but that might not be the 
best decision.

Any opinions if I make ChecksumFile an instantiated class?

ChecksumFile cf = new ChecksumFile(new File("random.jar"));
if( cf.valid() == false ) {
 cf.createChecksum( ChecksumAlgorithm.SHA1 );
}

wdyt?

  - but if not, it'd be better if the arg order of getChecksumFile and 
createChecksum and calculateChecksum were consistent (I would go with 
File first)

- I'd rename ChecksumFile as ChecksummedFile
- parseChecksum can be private?


I left that as public just to have it be easily unit tested. ;-)

- the two isValidChecksum(s) methods do different things. 
isValidChecksum should be isValidChecksum(Hash hash) { return 
isValidChecksums( new Hash[] { hash } ); }. Maybe another static 
convenience method is needed for the checksum file checkChecksumFile( 
File checksumFile ).


Legitimate fix.  Adding to my todo.



- Brett

On 09/04/2008, at 2:39 PM, Joakim Erdfelt wrote:
I've been taking a stab and removing some of our dependencies on 
various plexus components.


First up, plexus-digest.

I've taken the varied code from many locations and come up with a 
stand alone archiva-checksum lib/component that I hope to be able to 
integrate into archiva/trunk.


So ... uhm ... consider this a call for discussion. ;-)

- Joakim


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Re: Board Report for April 2008 review

[Joakim Erdfelt]

IIRC, I think we need to state that we have no new committers.

- Joakim

Maria Odea Ching wrote:

Hi Everyone,

We need to submit the board report this weekend. So far, below is what we
have in the report. Could you please review it? Some things might have been
missed as well, please feel free to add them :-)


Archiva Board Report for April 2008
---

* Archiva 1.0.2 has been released on April 9, 2008.

* Archiva is still in the process of moving out of the Maven area. The
source
  repository has been migrated into its own space. The mailing lists, and
the
  website and software publishing spaces still need to be created.


Thanks,
Deng

  

Re: [plexus work] archiva-checksums

[Joakim Erdfelt]

Not sure I understand what you are asking. :-(

There was a suggestion in the #archiva irc channel that we should offer 
the code in archiva-checksum to the commons-codec project.  An idea I 
fully support, but have no idea how to proceed with. ;-)


Also, Brett asked a passing question about how well archiva-checksum 
handles streaming.
I'd like to get some more information on expectations, then I can put 
together a few test cases to ensure that functionality.


- Joakim

James William Dumay wrote:

Joakim,
Is this based on any work from commons or have you implemented this
stuff from whats provided in the JDK?

James

On Tue, 2008-04-08 at 21:54 -0700, Joakim Erdfelt wrote:
  

Joakim Erdfelt wrote:

I've been taking a stab and removing some of our dependencies on 
various plexus components.


First up, plexus-digest.

I've taken the varied code from many locations and come up with a 
stand alone archiva-checksum lib/component that I hope to be able to 
integrate into archiva/trunk.


So ... uhm ... consider this a call for discussion. ;-)

- Joakim

  

Some more details...

These are 4 classes present in archiva-checksum
  1) org/apache/archiva/checksum/Hash.java
  2) org/apache/archiva/checksum/Hasher.java
  3) org/apache/archiva/checksum/Hex.java
  4) org/apache/archiva/checksum/ChecksumFile.java

This is how the replacements work ...

Hash.class is an enum identifying the types of Hash functions (currently 
only SHA1 and MD5), with a few details on ids that the hash techniques 
expose.

  This is similar in scope, but not a 100% replacement for ...
  org/codehaus/plexus/digest/Sha1Digester.java
  org/codehaus/plexus/digest/Md5Digester.java
  org/codehaus/plexus/digest/StreamingSha1Digester.java

Hasher.class is the main hashing routines, stream based, and has a few 
optimizations for performing bulk or group hashing based on a single 
stream, without processing the stream multiple times (one for each hash).

  Hasher.class replaces the following classes in plexus-digest
  org/codehaus/plexus/digest/Digester.java
  org/codehaus/plexus/digest/StreamingDigester.java

Hex.class is just a simple utility class to convert a byte array to a 
Hex string.

  It is a suitable replacement for plexus-digest
  org/codehaus/plexus/digest/Hex.java

ChecksumFile.class is the file specific implementation, for dealing with 
the .md5 and .sha1 files (parsing, validating, creating, etc..)

  It is a replacement for plexus-digest
  org/codehaus/plexus/digest/ChecksumFile.java
  org/codehaus/plexus/digest/DigestUtils.java
  And also covers the logic present in archiva-common too
  org/apache/maven/archiva/common/utils/Checksums.java

- Joakim



  

Re: [plexus work] archiva-checksums

[Joakim Erdfelt]

Joakim Erdfelt wrote:
I've been taking a stab and removing some of our dependencies on 
various plexus components.


First up, plexus-digest.

I've taken the varied code from many locations and come up with a 
stand alone archiva-checksum lib/component that I hope to be able to 
integrate into archiva/trunk.


So ... uhm ... consider this a call for discussion. ;-)

- Joakim


Some more details...

These are 4 classes present in archiva-checksum
 1) org/apache/archiva/checksum/Hash.java
 2) org/apache/archiva/checksum/Hasher.java
 3) org/apache/archiva/checksum/Hex.java
 4) org/apache/archiva/checksum/ChecksumFile.java

This is how the replacements work ...

Hash.class is an enum identifying the types of Hash functions (currently 
only SHA1 and MD5), with a few details on ids that the hash techniques 
expose.

 This is similar in scope, but not a 100% replacement for ...
 org/codehaus/plexus/digest/Sha1Digester.java
 org/codehaus/plexus/digest/Md5Digester.java
 org/codehaus/plexus/digest/StreamingSha1Digester.java

Hasher.class is the main hashing routines, stream based, and has a few 
optimizations for performing bulk or group hashing based on a single 
stream, without processing the stream multiple times (one for each hash).

 Hasher.class replaces the following classes in plexus-digest
 org/codehaus/plexus/digest/Digester.java
 org/codehaus/plexus/digest/StreamingDigester.java

Hex.class is just a simple utility class to convert a byte array to a 
Hex string.

 It is a suitable replacement for plexus-digest
 org/codehaus/plexus/digest/Hex.java

ChecksumFile.class is the file specific implementation, for dealing with 
the .md5 and .sha1 files (parsing, validating, creating, etc..)

 It is a replacement for plexus-digest
 org/codehaus/plexus/digest/ChecksumFile.java
 org/codehaus/plexus/digest/DigestUtils.java
 And also covers the logic present in archiva-common too
 org/apache/maven/archiva/common/utils/Checksums.java

- Joakim

[plexus work] archiva-checksums

[Joakim Erdfelt]

I've been taking a stab and removing some of our dependencies on various 
plexus components.


First up, plexus-digest.

I've taken the varied code from many locations and come up with a stand 
alone archiva-checksum lib/component that I hope to be able to integrate 
into archiva/trunk.


So ... uhm ... consider this a call for discussion. ;-)

- Joakim

Re: plan for MRM-159

[Joakim Erdfelt]

Heh, I can't grasp the nuances between Error handlings and update error 
handling.


The proxy connector has a few places an exception could occur.
(off the top of my head)

* Request for remote content results in hostname (dns) exception.
* Request for remote content results in auth exception.
* Request for remote content results in connection exception.
* Downloading the remote content fails midstream. (partial download)
* Can't create directory for remote content to download into
* Can't create file for remote content to download into (this is a temp 
file name, btw)

* Can't rename remote content (temp filename) to actual name.
* The client requesting the content has closed the connection early (no 
propogation issue here)

* Network proxy error.
* Exception while updating maven-metadata.xml file.
* Failed policy (checksum, and in the future, the pgp check)

- Joakim


Brett Porter wrote:

Hi,

For MRM-159 (should not respond with a 404 if proxying a file results 
in a remote error), I intend to add two options to the proxy connector:
* Error handling: propagate immediately, propagate at end if not 
successful (default), ignore
* Update error handling: propagate always, propagate if artifact not 
present (default)


Please tell me now if these aren't descriptive enough, firstly :)

For the one that propagates at the end, I'll look into a way to list 
all the errors that occurred in the response.


WDYT?

Cheers,
Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

[ohloh] Update with new svn enlistment

[Joakim Erdfelt]

I updated the Apache Archiva project on ohloh.net

 http://www.ohloh.net/projects/6670

I added a new enlistment for the new subversion repository/trunk root.
I left the old one in place (until the new one registers at least 1 scan)

 enlistments: http://www.ohloh.net/projects/6670/enlistments

- Joakim

[JIRA] move from jira.codehaus.org to issues.apache.org?

[Joakim Erdfelt]

I'd like to start a discussion on moving the MRM jira from 
jira.codehaus.org to issues.apache.org/jira/ opinions?


- Joakim

mailing lists?

[Joakim Erdfelt]

so ... what's needed to move the archiva mailing lists?

- Joakim

Re: proposed structural change to the source repo

[Joakim Erdfelt]

I like it.
Lets do it now!

I'll update "other" sites with references to our new Archiva svn root. 
(like ohloh and statsvn)


- Joakim

Brett Porter wrote:
Since we're moving tomorrow anyway, I'd like to propose making the 
following change subsequently:


/archiva
 /archiva-docs
 /archiva-jetty
 /archiva-modules
   .. current structure under here

This means we can retain the one release, one build - but all the Java 
code sites under -modules. This allows us to put all the Java code 
reporting in there, and not pollute the -docs and the distro with it.


I think more changes can be made to the structure of -modules, but 
that can be done at a later time.


Any objections?

- Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Re: svn commit: r640315 - /maven/archiva/trunk/pom.xml

[Joakim Erdfelt]

$ mvn --version
Maven version: 2.0.7
Java version: 1.5.0_13
OS name: "linux" version: "2.6.22-14-generic" arch: "i386"

Configuring mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.1:run' -->
Configuring mojo 
'org.apache.maven.plugins:maven-assembly-plugin:2.1:single' -->
Configuring mojo 
'org.apache.maven.plugins:maven-clean-plugin:2.1.1:clean' -->
Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -->
Configuring mojo 
'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:testCompile' -->
Configuring mojo 
'org.apache.maven.plugins:maven-install-plugin:2.2:install' -->

Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar' -->
Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:sign' -->
Configuring mojo 
'org.apache.maven.plugins:maven-remote-resources-plugin:1.0-alpha-6:process' 
-->
Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -->
Configuring mojo 
'org.apache.maven.plugins:maven-resources-plugin:2.2:testResources' -->
Configuring mojo 
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:attach-descriptor' 
-->
Configuring mojo 
'org.apache.maven.plugins:maven-surefire-plugin:2.4.1:test' -->
Configuring mojo 
'org.apache.maven.plugins:maven-war-plugin:2.0.1:inplace' -->

Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' -->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:java' -->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:jpox-jdo-mapping' 
-->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:jpox-metadata-class' 
-->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:registry-reader' -->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:registry-writer' -->
Configuring mojo 
'org.codehaus.modello:modello-maven-plugin:1.0-alpha-15:xsd' -->
Configuring mojo 
'org.codehaus.mojo.appassembler:appassembler-maven-plugin:1.0-SNAPSHOT:create-repository' 
-->
Configuring mojo 
'org.codehaus.mojo.appassembler:appassembler-maven-plugin:1.0-SNAPSHOT:generate-daemons' 
-->

Configuring mojo 'org.codehaus.mojo:dependency-maven-plugin:1.0:copy' -->
Configuring mojo 'org.codehaus.mojo:jpox-maven-plugin:1.1.7:enhance' -->
Configuring mojo 
'org.codehaus.mojo:keytool-maven-plugin:1.0-beta-1:clean' -->
Configuring mojo 
'org.codehaus.mojo:keytool-maven-plugin:1.0-beta-1:genkey' -->
Configuring mojo 
'org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8:add-apps' -->
Configuring mojo 
'org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8:add-services' 
-->
Configuring mojo 
'org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8:assemble-app' 
-->
Configuring mojo 
'org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8:assemble-runtime' 
-->
Configuring mojo 
'org.codehaus.plexus:plexus-appserver-maven-plugin:2.0-alpha-8:package-app' 
-->
Configuring mojo 
'org.codehaus.plexus:plexus-maven-plugin:1.3.5:descriptor' -->
Configuring mojo 
'org.codehaus.plexus:plexus-maven-plugin:1.3.5:merge-descriptors' -->

maven-antrun-plugin: resolved to version 1.1 from repository central
maven-clean-plugin: resolved to version 2.1.1 from repository central
maven-compiler-plugin: resolved to version 2.0.2 from repository central
maven-idea-plugin: resolved to version 2.1 from repository central
maven-install-plugin: resolved to version 2.2 from repository central
maven-jar-plugin: resolved to version 2.2 from repository central
maven-resources-plugin: resolved to version 2.2 from repository central
org.apache.maven:maven-plugin-api:jar:2.0
org.apache.maven:maven-plugin-api:jar:2.0.1:runtime (selected for runtime)
org.apache.maven:maven-plugin-api:jar:2.0.4:runtime (selected for runtime)
org.apache.maven:maven-plugin-api:jar:2.0.5:runtime (selected for runtime)
org.apache.maven:maven-plugin-api:jar:2.0.6
org.apache.maven:maven-plugin-api:jar:2.0.6:runtime (selected for runtime)
org.apache.maven:maven-plugin-api:jar:2.0.7
org.apache.maven:maven-plugin-api:jar:2.0-beta-3:runtime (selected for 
runtime)
org.apache.maven:maven-plugin-api:jar:2.0:runtime (removed - nearer 
found: 2.0.4)

org.apache.maven:maven-plugin-api:jar:2.0:runtime (selected for runtime)
org.apache.maven:maven-plugin-descriptor:jar:2.0.4:runtime (selected for 
runtime)
org.apache.maven:maven-plugin-descriptor:jar:2.0.5:runtime (selected for 
runtime)

org.apache.maven:maven-plugin-descriptor:jar:2.0.7
org.apache.maven:maven-plugin-descriptor:jar:2.0:runtime (selected for 
runtime)
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.4:runtime 
(selected for runtime)
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.5:runtime 
(selected for runtime)

org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.6
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.7
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0:runtime 
(selected for runtime)
org.apache.mave

archiva-build-resources

[Joakim Erdfelt]

I've put together the starting point for archiva's checkstyle / pmd rules.

It's called archiva-build-resources, and is currently in the trunk/

I'd like to enable this module eventually for build checks on the 
various rules, but for now, it's just there and disabled.


To get this to work correctly, I think we should disconnect this module 
from the parent/child relationship to the archiva-parent pom.
The archiva-build-resources should probably be versioned seperately 
too.  So far, I've put it at 1-SNAPSHOT.


I've committed the changes to the top level pom.xml (but commented out).

- Joakim

Does modello still have a place?

[Joakim Erdfelt]

I've been wondering if we should reevaluate our decision to use modello, 
now that we've made a decision to use JDK 1.5 we've got Annotations, and 
we've also collectively agreed to use Spring, which has some integration 
points too.


It seems that we can drop modello and just use static classes and 
Annotations to get the jdo mapping pieces and xml bindings for the 
database backup/restore functions too.


wdyt?

- Joakim

Re: SVN move on March 29th

[Joakim Erdfelt]

+1 to the announced move on March 29th.

Brett Porter wrote:

Hi,

Any objections to me locking in the morning (Australian time) of Sat Mar 
29th to do the SVN move?


I wanted to give it a bit of time so 1.0.2 can go out first rather than 
interrupt that. We also need to move maven-meeper somewhere (I suggest 
the infrastructure repository). Carlos - wdyt?


Cheers,
Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/



--
- Joakim Erdfelt

Re: Apache Archiva is now a top level project at the ASF

[Joakim Erdfelt]

 __
  /\_   /  \
 /`/@),|  Hallmark Alpaca sends his |
 |  (~'  __|Congratulations to all of the   |
 _,--.___/  |\   Apache Archiva Devs on your|
   ,' , (   | \ Apache TLP Approval!|
   |  (  \  /  ||
\  )\_/  ,_/   |   May your community be vibrant|
/ /   ( |/ |   and fun, and your alpacas be |
   ( |( |  |   healthy and free of pests.   |
\| \|   \__/



Congrats Everyone!  :-)

- Joakim

Arnaud HERITIER wrote:

And girls. I think it is the only project in apache where we have two
women in the team ;-)

On Thu, Mar 20, 2008 at 12:17 PM, Michael Mallete <[EMAIL PROTECTED]> wrote:
  

you guys rock! \m/ congratulations :)




 On Thu, Mar 20, 2008 at 1:56 AM, Brett Porter <[EMAIL PROTECTED]> wrote:

 > Hi all,
 >
 > The board approved the resolution we submitted, so Archiva is now a TLP.
 >
 > I look forward to working with you all on moving forward with this!
 >
 > Cheers,
 > Brett
 >
 > --
 > Brett Porter
 > [EMAIL PROTECTED]
 > http://blogs.exist.com/bporter/
 >
 >






  



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

Re: moved the wiki

[Joakim Erdfelt]

Cool beans!

Should we update any links on the archiva site to point to this new wiki?

I'd like to start a discussion of using a wiki for the frontpage of 
Archiva's site too.

Like other apache projects do? ...

 OpenEJB: http://openejb.apache.org/
 Geronimo: http://geronimo.apache.org/
 OpenJPA: http://openjpa.apache.org/
 ServiceMix: http://servicemix.apache.org/home.html

- Joakim


Brett Porter wrote:

http://cwiki.apache.org/confluence/display/ARCHIVA/Index

I just did this by hand, so I apologise for losing history but it was 
never going to be feasible to import :(


Cheers,
Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Re: svn commit: r637515 - /maven/archiva/trunk/pom.xml

[Joakim Erdfelt]

Oh?
Didn't know that spring-test even existed.

Once we start migrating away our plexus scaffolding to spring, wouldn't 
we need spring too?


-Joakim

Brett Porter wrote:


On 16/03/2008, at 2:15 PM, [EMAIL PROTECTED] wrote:


* Adding spring as default dependency.


Why is this needed? I would expect we only need a spring dependency in 
testing (which should be spring-test), and in the webapp - we're not 
using any interfaces?


- Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Trunk has a build loop??

[Joakim Erdfelt]

I kicked off a build before dinner and came back to a build still in 
progress (over 2 hours!!)


Info..
$ mvn --version
Maven version: 2.0.7
Java version: 1.5.0_13
OS name: "linux" version: "2.6.22-14-generic" arch: "i386"

I used $ mvn clean install

This seemed strange so I did the following to see what was going on ...

$ mvn clean install | grep "\[INFO\] Building"

This is what I see ...

[INFO] Building Archiva
[INFO] Building Archiva Base
[INFO] Building Archiva Base :: Common
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-common/target/archiva-common-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Policies
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-policies/target/archiva-policies-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Configuration
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-configuration/target/archiva-configuration-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Model
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-model/target/archiva-model-1.1-SNAPSHOT.jar

[INFO] Building Archiva Consumers
[INFO] Building Archiva Consumer API
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-consumers/archiva-consumer-api/target/archiva-consumer-api-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: XML Tools
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-xml-tools/target/archiva-xml-tools-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Dependency Graph
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-dependency-graph/target/archiva-dependency-graph-1.1-SNAPSHOT.jar

[INFO] Building Archiva Repository Interface Layer
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-repository-layer/target/archiva-repository-layer-1.1-SNAPSHOT.jar

[INFO] Building Archiva Database
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-database/target/archiva-database-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Indexer
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-indexer/target/archiva-indexer-1.1-SNAPSHOT.jar

[INFO] Building Archiva Consumers :: Core Consumers
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-consumers/archiva-core-consumers/target/archiva-core-consumers-1.1-SNAPSHOT.jar

[INFO] Building Archiva Reporting
[INFO] Building Archiva Reporting :: Report Manager
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-reporting/archiva-report-manager/target/archiva-report-manager-1.1-SNAPSHOT.jar

[INFO] Building Archiva Reporting :: Artifact Reports
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-reporting/archiva-artifact-reports/target/archiva-artifact-reports-1.1-SNAPSHOT.jar

[INFO] Building Archiva Consumers :: Database Consumers
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-consumers/archiva-database-consumers/target/archiva-database-consumers-1.1-SNAPSHOT.jar

[INFO] Building Archiva Consumers :: Lucene Consumers
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-consumers/archiva-lucene-consumers/target/archiva-lucene-consumers-1.1-SNAPSHOT.jar

[INFO] Building Archiva Consumers :: GPG Signature Consumers
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-consumers/archiva-signature-consumers/target/archiva-signature-consumers-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Proxy
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-proxy/target/archiva-proxy-1.1-SNAPSHOT.jar

[INFO] Building Archiva Transactions
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-transaction/target/archiva-transaction-1.1-SNAPSHOT.jar

[INFO] Building Archiva Artifact Converter
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-artifact-converter/target/archiva-artifact-converter-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Repository Converter
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-base/archiva-converter/target/archiva-converter-1.1-SNAPSHOT.jar

[INFO] Building Archiva Reporting :: Metadata Reports
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-reporting/archiva-metadata-reports/target/archiva-metadata-reports-1.1-SNAPSHOT.jar

[INFO] Building Archiva Reporting :: Project Reports
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-reporting/archiva-project-reports/target/archiva-project-reports-1.1-SNAPSHOT.jar

[INFO] Building Archiva Base :: Scheduled Tasks
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-scheduled/target/archiva-scheduled-1.1-SNAPSHOT.jar

[INFO] Building Archiva Web
[INFO] Building Archiva Web :: Applet
[INFO] Building jar: 
/home/jerdfelt/code/archiva/trunk/archiva-web/archiva-applet/target/archiva-applet-1.1-SNAPSHOT.jar

Re: WIP/POC archiva-jarinfo

[Joakim Erdfelt]

Whoops.

Forgot to mention that you can find this code at ...
https://svn.apache.org/repos/asf/maven/sandbox/trunk/archiva/archiva-jarinfo

- Joakim

Joakim Erdfelt wrote:
I've been working on and off on a few different archiva related tools 
/ tasks / libs.


Brett and Wendy convinced me to upload what I got and outline what 
I've got in mind to let the creative juices flow. (besides, I'm 
running out of time to commit to archiva, so this work will be slow to 
progress if i do it alone).


Concept: archiva-jarinfo.

A library for jar indexing / searching / identification for local 
repositories, arbitrary directories of jars, and even remote 
repositories.


For use by ...

 * Archiva itself as a possible replacement for repository scanning, 
indexing, and searching.
   (Searching on checksums, filenames, classnames, imports, 
identification fields, and even public / exposed methods)
 * Archiva RepoMan WebStart Tool - a tool I've been wanting to help 
identify and upload content to an Archiva repository.
 * Archiva Maven Plugin - imagine typing $ mvn archiva:search 
-Dquery=Logger and getting hits on
   log4j, slf4j, commons-logging, plexus-logging, etc...  found from 
results from local repository and remote repository.
 * Q4E integration - adding some ability to q4e to search local 
repository and remote repositories for dependencies.


Some details.

(Some of this exists and works, Some of it does not, remember this is 
a Work in Progress)


The existing repository scanning / indexing in Archiva server makes 
some assumptions that have proven to be misguided (such as only 
searching for new content based on timestamp).  The new approach that 
archiva-jarinfo takes is to mitigate the time consuming part of the 
scan that the new content timestamp check attempts to avoid, the 
processing of the jar file.
This is done by checking for a new xml file with the contents of the 
jar file (called ${artifact}-${version}.jarinfo), if the file exists, 
it's up to date, if it doesn't exist, the jar details are collected 
and the jarinfo file is created.
I've seen this useful if you sync or copy repository directories too. 
as the jarinfo files come along for the ride and reduce the 
requirements for archiva to determine the jar details yet again.
The scan creates a Jar Info Bundle (*.jib file) that is just a jar 
file with all of the *.jarinfo xml files in it, for consumption by 
remote JarInfo clients to use for indexing purposes.


The JarInfo client uses the JarInfo lib to create an index for 
checksums, jar content filenames, and public/exposed bytecode 
information.


The JarInfo client can search local repos, remote repos, and even 
arbitrary directories of jar files.


The JarInfo client can take an anonymous Jar file and perform a series 
of identification checks in an attempt to identify the Jar file based 
on jar file contents, and even similarity to jar files found in the 
JarInfo indexes.


That's all the info I can squeeze out tonite, hopefully someone else 
will find this useful.


Thanks,
- Joakim

WIP/POC archiva-jarinfo

[Joakim Erdfelt]

I've been working on and off on a few different archiva related tools / 
tasks / libs.


Brett and Wendy convinced me to upload what I got and outline what I've 
got in mind to let the creative juices flow. (besides, I'm running out 
of time to commit to archiva, so this work will be slow to progress if i 
do it alone).


Concept: archiva-jarinfo.

A library for jar indexing / searching / identification for local 
repositories, arbitrary directories of jars, and even remote repositories.


For use by ...

 * Archiva itself as a possible replacement for repository scanning, 
indexing, and searching.
   (Searching on checksums, filenames, classnames, imports, 
identification fields, and even public / exposed methods)
 * Archiva RepoMan WebStart Tool - a tool I've been wanting to help 
identify and upload content to an Archiva repository.
 * Archiva Maven Plugin - imagine typing $ mvn archiva:search 
-Dquery=Logger and getting hits on
   log4j, slf4j, commons-logging, plexus-logging, etc...  found from 
results from local repository and remote repository.
 * Q4E integration - adding some ability to q4e to search local 
repository and remote repositories for dependencies.


Some details.

(Some of this exists and works, Some of it does not, remember this is a 
Work in Progress)


The existing repository scanning / indexing in Archiva server makes some 
assumptions that have proven to be misguided (such as only searching for 
new content based on timestamp).  The new approach that archiva-jarinfo 
takes is to mitigate the time consuming part of the scan that the new 
content timestamp check attempts to avoid, the processing of the jar file.
This is done by checking for a new xml file with the contents of the jar 
file (called ${artifact}-${version}.jarinfo), if the file exists, it's 
up to date, if it doesn't exist, the jar details are collected and the 
jarinfo file is created.
I've seen this useful if you sync or copy repository directories too. as 
the jarinfo files come along for the ride and reduce the requirements 
for archiva to determine the jar details yet again.
The scan creates a Jar Info Bundle (*.jib file) that is just a jar file 
with all of the *.jarinfo xml files in it, for consumption by remote 
JarInfo clients to use for indexing purposes.


The JarInfo client uses the JarInfo lib to create an index for 
checksums, jar content filenames, and public/exposed bytecode information.


The JarInfo client can search local repos, remote repos, and even 
arbitrary directories of jar files.


The JarInfo client can take an anonymous Jar file and perform a series 
of identification checks in an attempt to identify the Jar file based on 
jar file contents, and even similarity to jar files found in the JarInfo 
indexes.


That's all the info I can squeeze out tonite, hopefully someone else 
will find this useful.


Thanks,
- Joakim

Re: svn commit: r634361 - in /maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src: main/java/org/apache/maven/archiva/repository/project/filters/ test/java/org/apache/maven/

[Joakim Erdfelt]

t/java/org/apache/maven/archiva/repository/project/filters/ProjectModelExpressionExpanderTest.java 
Thu Mar  6 09:40:26 2008

@@ -91,7 +91,7 @@
assertEquals( "Dependency [" + dep.getArtifactId() + "] 
Version", "1.0-SNAPSHOT", dep.getVersion() );

}
}
-
+
/**
 * [MRM-487] pom version is not resolved
 * [MRM-488] properties in pom are not resolved (at least while 
browsing)

@@ -112,10 +112,16 @@
String evaluatedModelText = toModelText( filteredModel );

// Test xml buffer for the existance of an unevaluated 
expression.

+boolean foundUnevaluated = false;
if ( evaluatedModelText.indexOf( "${" ) != ( -1 ) )
{
System.err.println( "Found Expression:\n" + 
evaluatedModelText );

-fail( "Found Unevaluated Expression. (see System.err)" );
+foundUnevaluated = true;
+}
+
+if ( foundUnevaluated )
+{
+fail( "Found Unevaluated Expression. (see System.err for 
details)" );

}
}


Modified: 
maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/repositories/default-repository/org/apache/maven/test/2.0.4-SNAPSHOT/test-2.0.4-SNAPSHOT.pom 

URL: 
http://svn.apache.org/viewvc/maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/repositories/default-repository/org/apache/maven/test/2.0.4-SNAPSHOT/test-2.0.4-SNAPSHOT.pom?rev=634361&r1=634360&r2=634361&view=diff 

== 

--- 
maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/repositories/default-repository/org/apache/maven/test/2.0.4-SNAPSHOT/test-2.0.4-SNAPSHOT.pom 
(original)
+++ 
maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/repositories/default-repository/org/apache/maven/test/2.0.4-SNAPSHOT/test-2.0.4-SNAPSHOT.pom 
Thu Mar  6 09:40:26 2008

@@ -102,7 +102,8 @@
TEST/Archiva


-${kb.site.url}/${prj.url.relative}
+
+
http://j.random.server.com/docs/${project.groupId}/${project.artifactId}/${project.version} 




scm:svn:${prj.svn}/${prj.svn.branch}




--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/




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

Re: Usage of appassembler-maven-plugin

[Joakim Erdfelt]

Arnaud HERITIER wrote:

Hi,

  I notice that we are using in the module archiva-jetty the
appassembler-maven-plugin v 1.0-SNAPSHOT from mojo and we didn't add the
snapshots repository of mojos in the pom. Is it wanted ?

  

I had only partial luck adding the codehaus snapshot repository as a fix.

The appassembler-maven-plugin seems to pull in a dependency on ...
 .../tanuki/wrapper-delta-pack/3.2.3/wrapper-delta-pack-3.2.3.tar.gz
as well, which isn't present on any repository (had to manually download 
it too)


I've always pondered the need for the appassembler.
I'm partial to just having jetty + tanuki expanded into the 
archiva-jetty/src/app/ and let the assembly plugin make the zip/tar.gz 
files.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]

Re: svn commit: r631999 - in /maven/archiva/branches/springy: archiva-base/archiva-common/ archiva-base/archiva-configuration/src/test/java/org/apache/maven/arch iva/configuration/

[Joakim Erdfelt]

Consider this a +1 from me.

This is very cool!

- Joakim


> It's OK for me.
>
>
> 2008/3/3, Brett Porter <[EMAIL PROTECTED]>:
>>
>> Cool. Is there anything left to do on here now, or should we look at
>> merging it to trunk?
>>
>>
>> On 02/03/2008, at 6:33 PM, nicolas de loof wrote:
>>
>> > That's what I supposed but just want to verify.
>> >
>> > 2008/3/1, Brett Porter <[EMAIL PROTECTED]>:
>> >>
>> >> It may not be necessary - presumably webwork's built in spring object
>> >> factory that you are now using does this already.
>> >>
>> >> On 01/03/2008, at 8:11 PM, nicolas de loof wrote:
>> >>
>> >>> Thanks for the link, I'll translate this idea to spring.
>> >>>
>> >>> cheers,
>> >>> Nicolas.
>> >>>
>> >>> 2008/2/29, Olivier Lamy <[EMAIL PROTECTED]>:
>> 
>>  Yes all per-lookup component must be released (for a long live
>>  application).
>>  To do that there is a interceptor to add in the webwork stack (look
>>  the note in the bottom of [1] yes sometimes it's possible to find a
>>  small documentation on plexus :-) )
>> 
>>  Maybe you can add a similar interceptor.
>> 
>>  --
>>  Olivier
>> 
>>  [1]
>> >> http://plexus.codehaus.org/plexus-components/plexus-xwork-
>> >> integration/
>> 
>>  2008/2/29, Brett Porter <[EMAIL PROTECTED]>:
>> > the reason in plexus was because each action was allocated on
>> > every
>> > request and not released - I just want to check whether that was
>> > the
>> > case again here. I think Olivier investigated it originally - is
>> > he
>> > listening here? :)
>> >
>> > - Brett
>> >
>> >
>> > On 29/02/2008, at 7:43 PM, nicolas de loof wrote:
>> >
>> >>>
>> >>>
>>   // Release existing
>>  -release( archivaConfiguration );
>>  +//  FIXME spring equivalent ?
>>  release( archivaConfiguration
>>  );
>> >>>
>> >>> I don't know if spring takes care of managing them itself -
>> >>> but we
>> >>> need to look into this since we used to have leaks from the
>> >>> webapp
>> >>> when it never released the components.
>> >>>
>> >>>
>> >> AFAIK there is no way in spring to "remove" a bean from the
>> >> context.
>> >>
>> >> Not sure what is the requirement here, I suppose we want to FORCE
>> >> the
>> >> singleton "archivaConfiguration" bean to get reloaded /
>> >> refreshed.
>> >>
>> >> The best option IMHO is to use use a BeanNameAutoProxyCreator to
>> >> create a
>> >> proxy for the "archivaConfiguration" singleton. An interceptor
>> >> could
>> >> cache
>> >> the active concrete implementation instance, declared as
>> >> prototype,
>> >> and
>> >> expose a "release()" management method to force a new lookup.
>> >>
>> >> Nicolas.
>> >
>> >
>> > --
>> > Brett Porter
>> > [EMAIL PROTECTED]
>> > http://blogs.exist.com/bporter/
>> >
>> >
>> 
>> >>
>> >> --
>> >> Brett Porter
>> >> [EMAIL PROTECTED]
>> >> http://blogs.exist.com/bporter/
>> >>
>> >>
>>
>> --
>> Brett Porter
>> [EMAIL PROTECTED]
>> http://blogs.exist.com/bporter/
>>
>>
>

Re: [VOTE] Request Archiva graduation to a TLP

[Joakim Erdfelt]

+1

- Joakim

Maria Odea Ching wrote:

Hi Everyone,

As discussed in the Archiva dev list, below is the proposal for the Archiva TLP.
Please vote on whether to make this proposal a formal request to the Maven
PMC to apply for graduation.



[ ] +1
[ ] 0
[ ] -1

Thanks,
Deng


Establish the Apache Archiva Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the Foundation's

purpose to establish a Project Management Committee charged with
the creation and maintenance of open-source software related 
to the management of build repositories and to the storage and retrieval of 
the build system artifacts residing in them.



NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Archiva PMC", be and
hereby is established pursuant to Bylaws of the Foundation; and
be it further


RESOLVED, that the Apache Archiva PMC be and hereby is
responsible for the creation and maintenance of software related
to the management of build repositories and to the storage and retrieval of 
the build system artifacts residing in them based on software licensed


to the Foundation; and be it further

RESOLVED, that the office of "Vice President, Apache Archiva" be
and hereby is created, the person holding such office to serve
at the direction of the Board of Directors as the chair of the

Apache Archiva PMC, and to have primary responsibility for
management of the projects within the scope of responsibility of
the Apache Archiva PMC; and be it further

RESOLVED, that the persons listed immediately below be and

hereby are appointed to serve as the initial members of the
Apache Archiva PMC:

Fabrice Bellingard ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Maria Odea Ching ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)

Nicolas de Loof ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Joakim Erdfelt ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Arnaud Heritier ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)

Dennis Lundberg ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Jesse McConnell ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Brett Porter ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)

Edwin Punzalan ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Carlos Sanchez ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Wendy Smoak ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)

John Tolentino ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)
Emmanuel Venisse ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Maria Odea Ching be

appointed to the office of Vice President, Apache Archiva, to
serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until death,
resignation, retirement, removal or disqualification, or until a

successor is appointed; and be it further

RESOLVED, that the initial Apache Archiva PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the

Apache Archiva Project; and be it further

RESOLVED, that the initial Apache Archiva PMC be and hereby is
tasked with the migration and rationalization of the Apache
Maven PMC Archiva subproject; and be it further

RESOLVED, that all responsibility pertaining to the Maven Archiva
sub-project and encumbered upon the Apache Maven PMC
are hereafter discharged.
  






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

Re: Lunce 2.1 for trunk

[Joakim Erdfelt]

+1 for going all the way to Lucene 2.3.1

- Joakim

James William Dumay wrote:

After a few words on IRC with Joakim we should jump straight to 2.3.1


James

On Thu, 2008-02-28 at 12:08 +1100, James William Dumay wrote:
  

Hey guys,
Just looking over the change log for Lucene 2.1 - might be worth an
upgrade.

http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_1_0/CHANGES.txt


Any objections?

James




  

Re: from plexus to spring...

[Joakim Erdfelt]

nicolas,

This is way cool! 
A very slick way of helping the transition.

I'm looking forward to some free time to dive into it.

- Joakim


nicolas de loof wrote:

Hi Rahul,

Thanks for yout interest for this plexus-to-spring migration helper.
The code is still early experimental and requires some more testing : it
only has been tested on 2 archiva testcases and requires many fixes and
testcases to get stable.

Please give me one week to test it more, add debugging logs and better error
handling / reporting : The current code is not really easy to debug when
some unexpected IoC occur... I also may improve support for plexus lifecycle
and specificities, as long as I discover requirements from archiva codebase.

It is allready isolated from archiva for reuse, and can move to plexus when
ready (I've no access to plexus svn).

I promise to inform you about progress ;-)

Nicolas.

2008/2/25, Rahul Thakur <[EMAIL PROTECTED]>:
  

Hi Nicolas,

Sorry, I have looked at the recent updates to the code, hence my
question. Is this 'ready' enough to be used outside Archiva? I'd like to
integrate this into Continuum.

I think it might make sense to have this module in Plexus SVN repo - wdyt?

Good stuff!

Cheers,
Rahul

nicolas de loof wrote:


Hello,

I've repackaged and improved the spring support for plexus components in
  

a


dedicated poject
-->

  

https://svn.apache.org/repos/asf/maven/archiva/branches/springy/plexus-spring/


This new module provides runtime translation from plexus component
descriptors to a Spring XML context, using a simple XSL file and a
  

custom


ApplicationContext. Any existing plexus jars can then be used in a
  

spring


context.

It defines a custom  spring-namespace. Under the hood a custom
FactoryBean handles plexus components field-injection and (some)
  

lifecycle


interfaces. As I discover plexus features by testing on archiva, I'd be
pleased to get more infos on plexus IoC specificities.

It also provides a PlexusInSpringTestCase that is a replacement class
  

for


PlexusTestCase, providing equivalent methods and behavior.

I've applied this (in springy branch) on archiva-policies and
  

archiva-proxy


(with some test failures in latest I have to investigate)

On this basis and with the required improvements, I thing this is a nice
  

way


to move archiva (or other plexus-based app) to spring and then gradually
refactor plexus components, either using Spring annotation or XML
  

context


files (my +1 for context files).

Nicolas.


  


  

Re: test failures on trunk after commons-io upgrade

[Joakim Erdfelt]

I found the problem.
A behavior change in FileUtils.writeStringToFile() for the default 
configuration creation step in conjunction with multiple test executions 
without running clean seems to trigger the problem in archiva-configuration.


Continuum would never have triggered this issue as it runs "mvn clean 
test" which would have eliminated one part of the issue.
And running in Windows wouldn't have triggered the issue, as the 
directory "*invalid:path*" couldn't be created (as it is intended).


It should be fixed in trunk now.

- Joakim

Brett Porter wrote:

Hi Joakim,

James pointed out trunk wasn't building and it seems that the upgrade 
of commons-io was the cause. I can't just roll that back as there are 
now other dependencies on the new API.


Can you find out what's up?

- Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Re: should Archiva talk about requesting to become a top level project?

[Joakim Erdfelt]

Here's my +1

Initially I was a little skeptical that we could pull off a TLP, I had 
this feeling that we hadn't yet reached the level of interest and 
participation that Continuum has, but since this email I've been reading 
the comments about Archiva online from people using / installing it.


Wow, are people talking about it.  So far it's mostly positive. yay! 
(Congrats everyone!)


Example: Maven Repository Manager - why we chose Archiva
http://java.dzone.com/blogs/mrjohnsmart/2008/02/19/maven-repository-managers-why-

So, with this week of study, I feel that my own critical view of Archiva 
of today is just flat out wrong.

Can it improve? Sure.
Does it work? Very well.
It is perfect? Does it matter? after all what software is perfect? (with 
the exception of maybe unix /bin/true and /bin/false)


Looking forward to the TLP.  Lets do it.

- Joakim


Brett Porter wrote:
The discussions this week have been pretty healthy, releases going 
smoothly, and there is user and developer interest.


Today, Continuum has graduated to be a top level project and I feel 
Archiva is well on track. What do others think?


BTW, SVN lists the following committers (snipped a couple of inactive 
ones):

aheritier
bayard
bellingard
brett
carlos
dennisl
epunzalan
evenisse
jmcconnell
joakime
jtolentino
nicolas
oching
wsmoak

There is both good numbers and diversity here. Though some have not 
committed in a while, many are participating in the dev list so I do 
feel like there's enough oversight to move forward. Is there anything 
out of date in that list?


Is there anyone lurking that is looking to get involved but not sure 
how? :)


Cheers,
Brett




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

RBAC vs JASS/Roles (was: Re: Plan to migrate towards Spring?)

[Joakim Erdfelt]

nicolas de loof wrote:

"Integrate RedBack / Spring into Archiva."

What is the advantage of redback compared to spring-security (aka "acegi") ?

spring-security allready supports role-based secutiry, DB user store and
"remember me".

Nico.
  

Redback is an RBAC implementation.

RBAC at NIST - http://csrc.nist.gov/groups/SNS/rbac/
RBAC FAQ - http://csrc.nist.gov/groups/SNS/rbac/faq.html
RBAC on Wikipedia - http://en.wikipedia.org/wiki/RBAC

Spring and Acegi do not have an RBAC implementation.

The Redback <--> Spring integration is likely to take the form of 
another acegi authorization provider, but it's still a little early yet 
to speculate on how this will occur.


A more general question would be ... do we need RBAC for Archiva?  or 
can we get away with standard JAAS Roles?


- Joakim

Re: Plan to migrate towards Spring?

[Joakim Erdfelt]

We also have a few of these tasks as dependent on the integration of 
Spring into the code tree.


If we phase in the Spring support, and try to use spring and plexus at 
the same time we can't phase those tasks in because it'll likely break 
the plexus support.


A rough timeline / order of tasks.

Isolated Changes, No Spring Dependency.
#)  Replace plexus-cli with commons-cli
#)  Replace plexus CommandLine with ProcessBuilder
#)  Replace plexus-digest with commons-codec implementation.
#)  Bring plexus-expression-evaluator into archiva code-tree.
#)  Use slf4j instead of plexus logger.
#)  Use commons-io to replace plexus-utils equivalents.
#)  Use commons-lang to replace plexus-utils equivalents.
#)  Create AnonymousProjectReader
#)  Migrate away from plexus-webdav to atlassian DAVServlet
#)  Migrate webwork/xwork to Struts 2

Changes Depending on Spring Integration.

#)  Create jetty bundle (MRM-688)
#)  Add Spring deps into existing codebase.
#)  Create alternative descriptors to use Spring for existing codebase.
   (At this point in time we now have a plexus and spring option.
We could attempt to set up a profile to use one over the other)
#)  Switch plexus-registry for PlexusJavaConfig
#)  Migrate plexus-cache to SpringCache
#)  Switch from JDO/JPox to JPA.
#)  Help RedBack use Spring.
#)  Integrate RedBack / Spring into Archiva.
#)  Switch plexus-scheduler for SpringScheduler
#)  Switch plexus-taskqueue for other Queue (JMS?)

(More comments inline)

Brett Porter wrote:


On 19/02/2008, at 9:37 AM, Joakim Erdfelt wrote:


org.codehaus.plexus.cache.Cache;

Used:
  archiva-repository-layer
  archiva-policies
Plan:
  Use ehcache directly
  or use Spring Caching (which uses ehcache)


the latter sounds best. Also worth reviewing whether this is a design 
issue - I'm surprised the policies needs a cache?


The cache-failures-policy uses it.
Easy, Once Spring is in place.




org.codehaus.plexus.commandline.DefaultExecutableResolver;
org.codehaus.plexus.commandline.ExecutableResolver;

Used:
  archiva-webapp-test
Plan:
  Investigate Need.


agreed.



  Fork into archiva if truely needed.


well - there should be no problem with using plexus-utils if it 
provides something for the time being. commons-exec did start moving 
again too, I noticed.


Nice.  Haven't looked at commons-exec yet.
I fear archiva-webapp-tests is woefully out of date.  Do we limp it 
along?  Archive it?  Send it to sandbox?






org.codehaus.plexus.tools.cli.AbstractCli;

Used:
  archiva-cli
Plan:
  Use commons-cli instead.


I also like the one by Sam Pullara that I used in the continuum data 
management tools - you might like to check it out (uses annotations)


I'll check it out, sounds nifty.  But honestly, do we really need 
archiva-cli ? ;-)
It would be easy enough to do, has no dependency on Spring and would 
remove a dependency on Plexus.







org.codehaus.plexus.util.cli.Commandline;
org.codehaus.plexus.util.cli.CommandLineUtils;
org.codehaus.plexus.util.cli.StreamConsumer;
org.codehaus.plexus.util.cli.WriterStreamConsumer;

Used:
  archiva-webapp-test
Plan:
  Use JDK 1.5 and java.lang.ProcessBuilder


Sounds good if it has the necessary functionality.


Its easy enough to use.  Used it in a bunch of places.
Our needs within archiva-webapp-test seems straight forward enough.
This would be easy to do, has no dependency on Spring or Plexus.





org.codehaus.plexus.component.repository.exception.ComponentLifecycleException; 

org.codehaus.plexus.component.repository.exception.ComponentLookupException; 


org.codehaus.plexus.context.Context;
org.codehaus.plexus.context.ContextException;
org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializationException; 


org.codehaus.plexus.personality.plexus.lifecycle.phase.Startable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.StartingException; 

org.codehaus.plexus.personality.plexus.lifecycle.phase.StoppingException; 


org.codehaus.plexus.PlexusConstants;
org.codehaus.plexus.PlexusContainer;
org.codehaus.plexus.PlexusTestCase;

Used:
  archiva-cli
  archiva-repository-layer
  archiva-webapp
  archiva-artifact-reports
  archiva-configuration
  archiva-core-consumers
  archiva-database
  archiva-database-consumers
  archiva-indexer
  archiva-lucene-consumers
  archiva-proxy
  archiva-scheduled
  archiva-webapp
Plan:
  Switch to Spring Container.


We need to assess the impact of this on the webapp - I think we can 
take all the plexus-isms out of there and just use the annotations, 
then we could switch to the spring objectfactory pretty easily.


Well, I'm worried about the POJOs using the Plexus specifics like 
Initializable, Startable, ContextAware, etc...

Those will be hard to coexist with Spring I suspect.
This will be time consuming, and difficult to do.





org.codeh

Plan to migrate towards Spring?

[Joakim Erdfelt]

I've felt that we need to migrate our choice of IoC (plexus) towards a 
better documented and better supported container (I'm leaning towards 
Spring)


I also recognize that this kind of change can't be done quickly or in a 
big-bang approach.
I've started an assessment of the plexus usage within Archiva and have 
planned out a first draft on what we can do to change that usage.


There are plenty of plexus components that need to be migrated before we 
can make the change to use a container such as spring.  There's also the 
whole Redback package that would need to be migrated as well.


So here's my first draft.
If there is interest, we can start to plan, schedule, and do the changes 
in small increments.
This should probably live as a document in the wiki, but for now I think 
we can discuss this in the mailing list.


org.codehaus.plexus.cache.Cache;

 Used:
   archiva-repository-layer
   archiva-policies
 Plan:
   Use ehcache directly
   or use Spring Caching (which uses ehcache)

org.codehaus.plexus.commandline.DefaultExecutableResolver;
org.codehaus.plexus.commandline.ExecutableResolver;

 Used:
   archiva-webapp-test
 Plan:
   Investigate Need.
   Fork into archiva if truely needed.

org.codehaus.plexus.tools.cli.AbstractCli;

 Used:
   archiva-cli
 Plan:
   Use commons-cli instead.

org.codehaus.plexus.util.cli.Commandline;
org.codehaus.plexus.util.cli.CommandLineUtils;
org.codehaus.plexus.util.cli.StreamConsumer;
org.codehaus.plexus.util.cli.WriterStreamConsumer;

 Used:
   archiva-webapp-test
 Plan:
   Use JDK 1.5 and java.lang.ProcessBuilder

org.codehaus.plexus.component.repository.exception.ComponentLifecycleException;
org.codehaus.plexus.component.repository.exception.ComponentLookupException;
org.codehaus.plexus.context.Context;
org.codehaus.plexus.context.ContextException;
org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializationException;
org.codehaus.plexus.personality.plexus.lifecycle.phase.Startable;
org.codehaus.plexus.personality.plexus.lifecycle.phase.StartingException;
org.codehaus.plexus.personality.plexus.lifecycle.phase.StoppingException;
org.codehaus.plexus.PlexusConstants;
org.codehaus.plexus.PlexusContainer;
org.codehaus.plexus.PlexusTestCase;

 Used:
   archiva-cli
   archiva-repository-layer
   archiva-webapp
   archiva-artifact-reports
   archiva-configuration
   archiva-core-consumers
   archiva-database
   archiva-database-consumers
   archiva-indexer
   archiva-lucene-consumers
   archiva-proxy
   archiva-scheduled
   archiva-webapp
 Plan:
   Switch to Spring Container.

org.codehaus.plexus.digest.ChecksumFile;
org.codehaus.plexus.digest.Digester;
org.codehaus.plexus.digest.DigesterException;

 Used:
   archiva-policies
   archiva-commons
   archiva-core-consumers
   archiva-transaction
   archiva-database-consumers
 Plan:
   Migrate to commons-codec

org.codehaus.plexus.evaluator.DefaultExpressionEvaluator;
org.codehaus.plexus.evaluator.EvaluatorException;
org.codehaus.plexus.evaluator.ExpressionEvaluator;
org.codehaus.plexus.evaluator.ExpressionSource;
org.codehaus.plexus.evaluator.sources.PropertiesExpressionSource;
org.codehaus.plexus.evaluator.sources.SystemPropertyExpressionSource;

 Used:
   archiva-repository-layer
   archiva-configuration
 Plan:
   Migrate expression-evaluator to archiva codebase.

org.codehaus.plexus.i18n.I18N;

 Used:
   archiva-converter
 Plan:
   Migrate to standard JDK i18n pattern.

org.codehaus.plexus.jdo.DefaultConfigurableJdoFactory;
org.codehaus.plexus.jdo.JdoFactory;

 Used:
   archiva-scheduled
   archiva-database
 Plan:
   Migrate to JDK 1.5 + JPA + Annotations

org.codehaus.plexus.logging.AbstractLogEnabled;
org.codehaus.plexus.logging.Logger;

 Used:
   archiva-repository-layer
   archiva-webapp
 Plan:
   Use slf4j directly

org.codehaus.plexus.redback.authentication.AuthenticationDataSource;
org.codehaus.plexus.redback.authentication.AuthenticationException;
org.codehaus.plexus.redback.authentication.AuthenticationResult;
org.codehaus.plexus.redback.authorization.AuthorizationException;
org.codehaus.plexus.redback.authorization.AuthorizationResult;
org.codehaus.plexus.redback.keys.KeyManager;
org.codehaus.plexus.redback.keys.memory.MemoryKeyManager;
org.codehaus.plexus.redback.policy.AccountLockedException;
org.codehaus.plexus.redback.policy.DefaultUserSecurityPolicy;
org.codehaus.plexus.redback.policy.MustChangePasswordException;
org.codehaus.plexus.redback.policy.UserSecurityPolicy;
org.codehaus.plexus.redback.rbac.RBACManager;
org.codehaus.plexus.redback.rbac.RbacManagerException;
org.codehaus.plexus.redback.rbac.Resource;
org.codehaus.plexus.redback.rbac.UserAssignment;
org.codehaus.plexus.redback.role.RoleManager;
org.codehaus.plexus.redback.role.RoleManagerException;
org.codehaus.plexus.redback.system.check.EnvironmentCheck;
org.codehaus.plexus.redback.system.DefaultSec

Re: Jira merge versions.

[Joakim Erdfelt]

Archiving the version might accomplish the same thing.
I see some checkboxes to exclude archived versions in the reports.

(heh, still spelling "archive" wrong)

As for reports, I can't find perma-links for most of them.
But here's an example: http://urltea.com/2qf2

- Joakim

Brett Porter wrote:

I'm unsure. I'd definitely leave 0.9 out on it's own regardless.

I kind of like the idea of merging, but I also hate to irreversibly 
lose information :)


Does archiving the alpha/beta releases achieve what you need? What is 
the noise in the reports you are referring to?


Thanks,
Brett

On 19/02/2008, at 6:05 AM, Joakim Erdfelt wrote:

I'd like to merge a few older released versions together in Jira (to 
help in reducing the noise on some of the reports.)


What I'd like to do ...

Take versions:
* 0.9
* 1.0-alpha-1
* 1.0-alpha-2
* 1.0-beta-1
* 1.0-beta-2
* 1.0-beta-3
* 1.0-beta-4

And merge them into:
* 1.0

Any objections?

- Joakim


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

Jira merge versions.

[Joakim Erdfelt]

I'd like to merge a few older released versions together in Jira (to 
help in reducing the noise on some of the reports.)


What I'd like to do ...

Take versions:
 * 0.9
 * 1.0-alpha-1
 * 1.0-alpha-2
 * 1.0-beta-1
 * 1.0-beta-2
 * 1.0-beta-3
 * 1.0-beta-4

And merge them into:
 * 1.0

Any objections?

- Joakim

Re: regression in beta-4 : server-side relocation broken

[Joakim Erdfelt]

A little bit too much of a coincidence that you should also be having a
relocation related problem.

I'll see what I can do to get some unit testing around this into place
on the RepositoryServlet tests.

- Joakim

Arnaud HERITIER wrote:
> I noticed a problem when I tested this version before the vote but i didn't
> find the time to check if it was a regression.
> It's with poi:poi:2.5.1 which is relocated to 2.5.1-final-20040804
> I don't know if it can be related to this issue
>
> Arnaud
>
> On Nov 14, 2007 6:20 PM, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
>
>   
>> Don't we have unit testing around the server side relocation?
>> If not, I think we need to get them into place as part of the solution
>> for MRM-595.
>>
>> - Joakim
>>
>> nicolas de loof wrote:
>> 
>>> MRM-595 created.
>>>
>>> As explain, there is two causes :
>>>
>>> 1. fetchContentFromProxies must be called prior to building the resource
>>> File
>>> 2. DavServerRequest getLogicalResource is not re-computed when request
>>> PathInfo changes.
>>>
>>>
>>> Nico.
>>>
>>>
>>>   
>> 
>
>
>   

Re: regression in beta-4 : server-side relocation broken

[Joakim Erdfelt]

Don't we have unit testing around the server side relocation?
If not, I think we need to get them into place as part of the solution
for MRM-595.

- Joakim

nicolas de loof wrote:
> MRM-595 created.
>
> As explain, there is two causes :
>
> 1. fetchContentFromProxies must be called prior to building the resource
> File
> 2. DavServerRequest getLogicalResource is not re-computed when request
> PathInfo changes.
>
>
> Nico.
>
>   

Re: small issue with maven1 (legacy) request resolution

[Joakim Erdfelt]

The path "org.apache.commons/jars/commons-io-1.3.2-sources.jar" is in
the wrong place.
That source jar should be in
"org.apache.commons/java-sources/commons-io-1.3.2-sources.jar"

Example: org.apache.camel/java-sources/camel-script-1.1.0-sources.jar

Again, m1 repos do not support classifiers.
The only reason this specific case works is that there is a special case
specific mapping for ...
  (type) "java-source" to (extension) "-sources.jar"

The current m1 file repo on people.apache.or has 1479 source jars in the
proper place. and 107 in the wrong place.
If you need classifiers, use maven 2 (that's where it was really introduced)

- Joakim

nicolas de loof wrote:
> That's right, I just forgot those ones :-/
>
> Requesting org.apache.commons/jars/commons-io-1.3.2-sources.jar also fails
> and is translated to
> org/apache/commons/commons-io/1.3.2-sources/commons-io-1.3.2-sources.jar
>
>
> But maybe this is NOT an issue : in maven1 world there is no classifier, and
> my backport should be put in "groupId/backports/artifact-backport.jar", the
> same way -sources.jar are put into "/java-sources/".
>
> Nico.
>
>
> 2007/11/13, Brett Porter <[EMAIL PROTECTED]>:
>   
>> Anything with source or javadoc :)
>>
>> - Brett
>>
>> On 13/11/2007, at 9:33 AM, nicolas de loof wrote:
>>
>> 
>>> MRM-593
>>>
>>> Do you know any artifact in central that uses a classifier ? I'd
>>> like to
>>> make the test on a non-SNAPSHOT artifact. Struts does not publish
>>> it's "j4"
>>> backported artifacts.
>>>
>>> Nico.
>>>
>>> 2007/11/13, Brett Porter <[EMAIL PROTECTED]>:
>>>   
 Thanks again Nicolas - I'm sure this is easily fixed, so it would be
 worth dropping in JIRA.

 - Brett

 On 13/11/2007, at 9:20 AM, nicolas de loof wrote:

 
> I have a lib that is built by maven2. It also has a retrotranslator
> version,
> with classifier "-backport", as part of the build process.
>
> When I deploy a SNAPSHOT of this lib, I get :
>
> [INFO] [deploy:deploy]
> [INFO] Retrieving previous build number from platina
> Uploading: /jmonit-1.0-alpha-1-SNAPSHOT.jar
> 78K uploaded
> ...
> Uploading: /jmonit-1.0-alpha-1-SNAPSHOT-backport.jar
> 47K uploaded
>
>
>
> When I try to get this lib from archiva, I get a 404, as the m1 path
> "org.jmonit/jars/jmonit-1.0-alpha-1-SNAPSHOT-backport.jar"
> gets converted to
> "
> org/jmonit/jmonit/1.0-alpha-1-SNAPSHOT-backport/jmonit-1.0-alpha-1-
> SNAPSHOT-backport.jar jmonit/1.0-alpha-1-SNAPSHOT-backport/jmonit-1.0-alpha-1-SNAPSHOT-
> backport.jar>
> "
> and not
> org/jmonit/jmonit/1.0-alpha-1-SNAPSHOT/jmonit-1.0-alpha-1-SNAPSHOT-
> backport.jar 1.0-alpha-1-SNAPSHOT-backport/jmonit-1.0-alpha-1-SNAPSHOT-
> backport.jar>
>
> --> The classifier is not recognized.
> Not tested with other dependencies, but I'm not sure we have good
> support
> for classifiers as part of m1 requests.
>
> Nico.
>   
 --
 Brett Porter - [EMAIL PROTECTED]
 Blog: http://www.devzuz.org/blogs/bporter/


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

Re: small issue with maven1 (legacy) request resolution

[Joakim Erdfelt]

(haven't read the rest of the thread yet)

the m1 repository format does not support classifiers.
never had, never will, and frankly, it can't ever support it as the
format is too ambiguous to detect classifier.

- Joakim

nicolas de loof wrote:
> I have a lib that is built by maven2. It also has a retrotranslator version,
> with classifier "-backport", as part of the build process.
>
> When I deploy a SNAPSHOT of this lib, I get :
>
> [INFO] [deploy:deploy]
> [INFO] Retrieving previous build number from platina
> Uploading: /jmonit-1.0-alpha-1-SNAPSHOT.jar
> 78K uploaded
> ...
> Uploading: /jmonit-1.0-alpha-1-SNAPSHOT-backport.jar
> 47K uploaded
>
>
>
> When I try to get this lib from archiva, I get a 404, as the m1 path
> "org.jmonit/jars/jmonit-1.0-alpha-1-SNAPSHOT-backport.jar"
> gets converted to
> "
> org/jmonit/jmonit/1.0-alpha-1-SNAPSHOT-backport/jmonit-1.0-alpha-1-SNAPSHOT-backport.jar
> "
> and not
> org/jmonit/jmonit/1.0-alpha-1-SNAPSHOT/jmonit-1.0-alpha-1-SNAPSHOT-backport.jar
>
> --> The classifier is not recognized.
> Not tested with other dependencies, but I'm not sure we have good support
> for classifiers as part of m1 requests.
>
> Nico.
>
>   

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

[Joakim Erdfelt]

+1 (am I too late again?)

- Joakim

Maria Odea Ching wrote:
> Hi Everyone,
>
> Archiva 1.0-beta-4 is now ready for release.
>
> The highlights of this release are:
> - security applied in repository browse and search (only those repositories
> where the user has permissions are accessible to that user)
> - fixes in repository purge
> - improved logging
> - additional fixes in proxy connectors configuration
>
> You can take a look at the release notes for Archiva 1.0-beta-4 here:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13818&styleName=Text&projectId=10980&Create=Create
>
> And the binaries, including the sources, signatures and checksums, can be
> downloaded here:
>
> http://people.apache.org/builds/maven/archiva/1.0-beta-4/
>
>
> Everyone is encouraged to vote and give their feedback.
>
> [ ]  +1  Release it!
> [ ]   0
> [ ]  -1  Don't release it, because...
>
> The vote will be open for 72 hours. So, cast your votes now ;-)
>
> Here's my +1
>
> Thanks,
> Deng
>
>   

Re: Release Archiva 1.0-beta-4

[Joakim Erdfelt]

Maria Odea Ching wrote:

Hi Everyone,

I'll be releasing Archiva 1.0-beta-4 in 3 hours in preparation for 1.0.That'll
be around 1:45PM my time. If there are any objections to this, please say so
immediately :-)


Excellent!
Stage the release ...
Prepare the vote ...

... Lets see if we can get this released before ApacheCon US starts on 
Monday.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]

Re: svn commit: r593414 - in /maven/archiva/trunk: archiva-database/pom.xml archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml archiva-web/archiva-webapp/pom.xml pom.xml

[Joakim Erdfelt]

Wha?

logging was working just fine.
Both in jetty:run execution and also in standalone version.

Confirmed by my ability to paste the contents of the log in the various 
jiras closed today. (as well as 1 email)


- Joakim

[EMAIL PROTECTED] wrote:

Author: brett
Date: Thu Nov  8 19:27:30 2007
New Revision: 593414

URL: http://svn.apache.org/viewvc?rev=593414&view=rev
Log:
[MRM-459] better rationalisation of commons-logging and partially revert 
r593206 as logging had stopped working altogether

Modified:
maven/archiva/trunk/archiva-database/pom.xml

maven/archiva/trunk/archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml
maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml
maven/archiva/trunk/pom.xml

Modified: maven/archiva/trunk/archiva-database/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-database/pom.xml?rev=593414&r1=593413&r2=593414&view=diff
==
--- maven/archiva/trunk/archiva-database/pom.xml (original)
+++ maven/archiva/trunk/archiva-database/pom.xml Thu Nov  8 19:27:30 2007
@@ -83,16 +83,6 @@
   commons-io
 
 
-  commons-logging
-  commons-logging
-  
-
-  logkit
-  logkit
-
-  
-
-
   log4j
   log4j
 

Modified: 
maven/archiva/trunk/archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml?rev=593414&r1=593413&r2=593414&view=diff
==
--- 
maven/archiva/trunk/archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml
 (original)
+++ 
maven/archiva/trunk/archiva-web/archiva-standalone/archiva-plexus-runtime/pom.xml
 Thu Nov  8 19:27:30 2007
@@ -64,7 +64,7 @@
 
 
   commons-logging
-  commons-logging
+  commons-logging-api
 
 
   org.apache.derby
@@ -115,7 +115,7 @@
   
src/plexus.properties
   target/plexus-archiva-runtime
   
-
commons-logging:commons-logging
+
commons-logging:commons-logging-api
 log4j:log4j
 
org.apache.derby:derby
 
org.codehaus.plexus:plexus-naming

Modified: maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml?rev=593414&r1=593413&r2=593414&view=diff
==
--- maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml (original)
+++ maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml Thu Nov  8 19:27:30 
2007
@@ -120,11 +120,6 @@
   slf4j-log4j12
 
 
-  commons-logging
-  commons-logging
-  runtime
-
-
   commons-lang
   commons-lang
 

Modified: maven/archiva/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?rev=593414&r1=593413&r2=593414&view=diff
==
--- maven/archiva/trunk/pom.xml (original)
+++ maven/archiva/trunk/pom.xml Thu Nov  8 19:27:30 2007
@@ -353,7 +353,7 @@
   
   
 commons-logging
-commons-logging
+commons-logging-api
     1.0.4
   
   


  



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

[Update 1] Documentation for 1.0

[Joakim Erdfelt]

I've added the appropriate outline as discussed here in the mailing list 
to svn.
The results of the new outline can be seen at 
http://people.apache.org/~joakime/archiva-1.0/ 



Here's the current outline (in email form)

-(snip)-

Introduction

   * Welcome
   * License
   * Download
   * Quick Start

Users Guide

   * Browsing
   * Searching
   * WebDAV Features
   * Using Repository ...
 o As a Maven 2 repository
 o As a Maven 1 repository
 o As an Ivy repository
   * Deploying to Repository
 o Using Maven 2
 o Using Maven 1
 o Using Ant

System Admin Guide

   * Structure of Archiva
   * Installing
 o Installing Standalone
 o Installing on Jetty
 o Installing on Tomcat
 o Installing on Geronimo
   * Databases
 o Embedded Derby DB
 o External MySQL
 o External PostgreSQL
   * Security
 o Roles
 o Using LDAP
   * Runtime Configuration
 o Repositories
 o Proxy Connectors
 o Network Proxies
 o Consumers
   * Reports
   * WebDAV Server
   * Repository Synch

Reference

   * FAQ
   * Community
 o How to Contribute
 o Development Team
 o Mailing Lists
 o Issue Tracking
 o Subversion Repository
   * Building / Hacking
   * Java APIDoc (javadoc)
   * Source Cross Reference
   * Test Cross Reference

-(snip)-

I've also stubbed out the various pages so that we can maximize the 
parallel documentation writing.


I'll take the following sections tomorrow...
Installing Archiva on Jetty.
Installing Archiva on Tomcat.
Using Archiva on MySQL.
Proxy Connectors.

Feel free to take any section / page / document / paragraph / sentence / 
word / punctuation that you want to :-)


- Joakim

Re: [Planning] Documentation for 1.0

[Joakim Erdfelt]

Maria Odea Ching wrote:
> The outline looks good to me (yay 1.0!)
>   

Time for a mexican wave...

 \o\ \o/ /o/

> I just have a few questions/suggestions here:
> - I assume that the proxying would fall under the "Using Archiva as a *
> Repository" sections?
>   

Actually, the section for Proxy Connectors is the place for that.
I think we need to be careful how we use the word "proxy" in our
documentation and be clear when we refer to "proxy connector" vs
"network proxy", as they are 2 separate concepts both with the word "proxy".

> - I think  we should also include Reporting/Reports in the Users Guide
>   

Reporting, yeah!  I knew I forgot something! doh!

> - On the "Consumers" section, maybe we could also put an example on how to
> create your own consumer and plug it into Archiva? I remember doing a
> separate consumer to demonstrate how this can be done (it's in the
> archiva-sandbox).
>   

That sounds like 2 concepts.  One documenting their purpose (in the
system admin user guide) and another documenting how to create a
consumer (more appropriate in the hacking / building documents).  wdyt?

> If you need some hands with the documentation, I'd be glad to help :)
>   

Help.  Yes!  Much appreciated.
I'll be getting the outline committed and the individual pages stubbed
out as soon as possible.
Any help should be easy at that point, as there should be be a clear
place / scope defined / for the documentation.

>
> Thanks,
> Deng
>   

No ... Thank you!

- Joakim

> On 11/7/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
>   
>>  I'm back to the planning and writing of the documentation for 1.0 ...
>>
>> I'd like to bounce the outline off of everyone to see if there are any
>> gaps / holes / completely idiotic decisions.
>>
>> *[Outline]*
>>
>>
>>- Introduction
>>   - Download *(we should make tar.gz, tar.bz2, zip, and war all
>>   available)*
>>- System Administrators Guide
>>   - Structure of Archiva. *(the filesystem reqs, database reqs,
>>   jndi usage, etc ...)*
>>- Installing
>>  - Installing Standalone
>>  - Installing on Jetty.
>>  - Installing on Tomcat.
>>  - Installing on Geronimo.
>>   - *(any others that we have documented anywhere?)*
>>   - Databases
>>  - Embedded Derby DB
>>  - Using MySQL
>>  - Using Postgres *(not even sure this works)*
>>   - Security
>>  - Roles
>>  - Configuring for LDAP. *(I'll need Jesse's help here)*
>>   - WebDAV features
>>- Runtime Configuration
>>- Repositories
>>  - Proxy Connectors
>>  - Network Proxies
>>  - Consumers
>>- Users Guide
>>   - Browsing.
>>   - Searching.
>>- WebDAV Features.
>>   - Using Archiva as a Maven 2 repository.
>>   - Using Archiva as a Maven 1 repository.
>>   - Using Archiva as an Ivy repository.
>>   - Deploying Artifacts to Archiva using Maven 2.
>>   - Deploying Artifacts to Archiva using Maven 1.
>>   - Deploying Artifacts to Archiva using Ant.
>>- Reference
>>   - FAQ. *(not sure what goes in here that isn't in the above
>>   sections, unless its just a list of topics / titles with links to the 
>> other
>>   content)*
>>- Building / Hacking.
>>- Mailing Lists.
>>   - Development Team.
>>   - Java APIDoc (javadoc).
>>- Source Cross Reference.
>>   - Test Cross Reference.
>>
>> Input / Comments / Hate Mail / General Nitpicks / Completely Different
>> Approaches are all welcome.
>>
>> --
>> - Joakim Erdfelt
>>   [EMAIL PROTECTED]
>>
>>
>> 
>
>   

Re: [Planning] Documentation for 1.0

[Joakim Erdfelt]

All excellent ideas!
I'll be implementing them first opportunity I get.

- Joakim

Franz Allan Valencia See wrote:
> Good day,
>
> Maybe, under the "Introduction" section should be something like this:
>
>- Introduction
>   - Overview ( what archiva is and what is solves )
>   - Quickstart
>  - Download *(we should make tar.gz, tar.bz2, zip, and war
>  all available)*
>  - Running it ( *with the default web server, db, etc
>  ...then just point to the "System Administrator's Guide" for more 
> info
>  *)
>
> Also, maybe the "Users Guide" should come first before the "System
> Administrators Guide" for two reasons:
> (a.) so that new users can already start playing with it, and
> (b.) This would probably be viewed more for its "Users Guide" than for its
> "System Administrators Guide".
>
> And lastly, I think there should be a "Community" and "How to contribute"
> sub-section in the "Reference" which would contain, the IRC, ML/forums, etc
> of the project. The "Community" information is one of the things I look for
> in an opensource project, so that I know where to direct my questions. And
> the "How to contribute" section would be nice as well not only for patches
> but for wiki as well :-)
>
> Just my 2 cents worth :-)
>
> - Franz
>
> On Nov 7, 2007 2:44 AM, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
>
>   
>>  I'm back to the planning and writing of the documentation for 1.0 ...
>>
>> I'd like to bounce the outline off of everyone to see if there are any
>> gaps / holes / completely idiotic decisions.
>>
>> *[Outline]*
>>
>>
>>- Introduction
>>   - Download *(we should make tar.gz, tar.bz2, zip, and war all
>>   available)*
>>- System Administrators Guide
>>   - Structure of Archiva. *(the filesystem reqs, database reqs,
>>   jndi usage, etc ...)*
>>- Installing
>>  - Installing Standalone
>>  - Installing on Jetty.
>>  - Installing on Tomcat.
>>  - Installing on Geronimo.
>>   - *(any others that we have documented anywhere?)*
>>   - Databases
>>  - Embedded Derby DB
>>  - Using MySQL
>>  - Using Postgres *(not even sure this works)*
>>   - Security
>>  - Roles
>>  - Configuring for LDAP. *(I'll need Jesse's help here)*
>>   - WebDAV features
>>- Runtime Configuration
>>- Repositories
>>  - Proxy Connectors
>>  - Network Proxies
>>  - Consumers
>>- Users Guide
>>   - Browsing.
>>   - Searching.
>>- WebDAV Features.
>>   - Using Archiva as a Maven 2 repository.
>>   - Using Archiva as a Maven 1 repository.
>>   - Using Archiva as an Ivy repository.
>>   - Deploying Artifacts to Archiva using Maven 2.
>>   - Deploying Artifacts to Archiva using Maven 1.
>>   - Deploying Artifacts to Archiva using Ant.
>>    - Reference
>>   - FAQ. *(not sure what goes in here that isn't in the above
>>   sections, unless its just a list of topics / titles with links to the 
>> other
>>   content)*
>>- Building / Hacking.
>>- Mailing Lists.
>>   - Development Team.
>>   - Java APIDoc (javadoc).
>>- Source Cross Reference.
>>   - Test Cross Reference.
>>
>> Input / Comments / Hate Mail / General Nitpicks / Completely Different
>> Approaches are all welcome.
>>
>> --
>> - Joakim Erdfelt
>>   [EMAIL PROTECTED]
>>
>>
>> 
>
>   

Re: [Planning] Documentation for 1.0

[Joakim Erdfelt]

Arnaud HERITIER wrote:

I can write this part : "Deploying Artifacts to Archiva using Maven 1."

The content is : "it's impossible using the webdav of archiva, you have to
use ftp, scp or another protocol available in the maven 1's artifact
plugin."

Arnaud
  


Shame that's the case.
We should add a jira for that (if it doesn't already exist).
And what part about archiva's webdav prevents this from working?

Joakim


On Nov 6, 2007 7:44 PM, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:

  

 I'm back to the planning and writing of the documentation for 1.0 ...

I'd like to bounce the outline off of everyone to see if there are any
gaps / holes / completely idiotic decisions.

*[Outline]*


   - Introduction
  - Download *(we should make tar.gz, tar.bz2, zip, and war all
  available)*
   - System Administrators Guide
  - Structure of Archiva. *(the filesystem reqs, database reqs,
  jndi usage, etc ...)*
   - Installing
 - Installing Standalone
 - Installing on Jetty.
 - Installing on Tomcat.
 - Installing on Geronimo.
  - *(any others that we have documented anywhere?)*
  - Databases
 - Embedded Derby DB
 - Using MySQL
 - Using Postgres *(not even sure this works)*
  - Security
 - Roles
 - Configuring for LDAP. *(I'll need Jesse's help here)*
  - WebDAV features
   - Runtime Configuration
   - Repositories
 - Proxy Connectors
 - Network Proxies
 - Consumers
   - Users Guide
  - Browsing.
  - Searching.
   - WebDAV Features.
  - Using Archiva as a Maven 2 repository.
  - Using Archiva as a Maven 1 repository.
  - Using Archiva as an Ivy repository.
  - Deploying Artifacts to Archiva using Maven 2.
  - Deploying Artifacts to Archiva using Maven 1.
  - Deploying Artifacts to Archiva using Ant.
   - Reference
  - FAQ. *(not sure what goes in here that isn't in the above
  sections, unless its just a list of topics / titles with links to the 
other
  content)*
   - Building / Hacking.
   - Mailing Lists.
  - Development Team.
  - Java APIDoc (javadoc).
   - Source Cross Reference.
  - Test Cross Reference.

Input / Comments / Hate Mail / General Nitpicks / Completely Different
Approaches are all welcome.

--
- Joakim Erdfelt
  [EMAIL PROTECTED]

[Planning] Documentation for 1.0

[Joakim Erdfelt]

I'm back to the planning and writing of the documentation for 1.0 ...

I'd like to bounce the outline off of everyone to see if there are any
gaps / holes / completely idiotic decisions.

[Outline]


  Introduction
  
Download (we should make tar.gz, tar.bz2, zip, and war all
available)

  
  System Administrators Guide
  
Structure of Archiva. (the filesystem reqs, database reqs,
jndi usage, etc ...)

Installing

  Installing Standalone
  Installing on Jetty.
  Installing on Tomcat.
  Installing on Geronimo.
  
  (any others that we have documented anywhere?)
  

Databases

  Embedded Derby DB
  Using MySQL
  Using Postgres (not even sure this works)
  

Security

  Roles
  Configuring for LDAP. (I'll need Jesse's help here)
  

WebDAV features

Runtime Configuration


  Repositories
  Proxy Connectors
  Network Proxies
  Consumers

  
  Users Guide
  
Browsing.
Searching.

WebDAV Features.
Using Archiva as a Maven 2 repository.
Using Archiva as a Maven 1 repository.
Using Archiva as an Ivy repository.
Deploying Artifacts to Archiva using Maven 2.
Deploying Artifacts to Archiva using Maven 1.
Deploying Artifacts to Archiva using Ant.

  
  Reference
  
FAQ. (not sure what goes in here that isn't in the above
sections, unless its just a list of topics / titles with links to the
other content)

Building / Hacking.

Mailing Lists.
Development Team.
Java APIDoc (javadoc).

Source Cross Reference.
Test Cross Reference.
  

Input / Comments / Hate Mail / General Nitpicks / Completely Different
Approaches are all welcome.

-- 
- Joakim Erdfelt
  [EMAIL PROTECTED]

Re: archiva-backend-security branch.

[Joakim Erdfelt]

Merge is complete.

- Joakim

Brett Porter wrote:

cool, go for it

On 06/11/2007, at 11:34 AM, Maria Odea Ching wrote:

Fine with me.. I've looked at some of the codes last night and it 
looks good :)


-Deng

Joakim Erdfelt wrote:

Brett Porter wrote:


On 05/11/2007, at 2:36 PM, Brett Porter wrote:



On 05/11/2007, at 2:32 PM, Joakim Erdfelt wrote:


There's nothing to present the "There are no repositories you have
access to" style message on the xwork side.
I should add that.


This doesn't seem to be the problem below though?


Ah, I understand - the action is calculating that first and passing 
it on as null instead of adding a message. Once this is fixed, it 
looks fine at runtime - taking a look at the commits now.


I added the "Access to No Repositories" screen / message.
OK to go ahead with the merge?

- Joakim





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




--
- Joakim Erdfelt
 [EMAIL PROTECTED]

Re: archiva-backend-security branch.

[Joakim Erdfelt]

Brett Porter wrote:


On 05/11/2007, at 2:36 PM, Brett Porter wrote:



On 05/11/2007, at 2:32 PM, Joakim Erdfelt wrote:


There's nothing to present the "There are no repositories you have
access to" style message on the xwork side.
I should add that.


This doesn't seem to be the problem below though?


Ah, I understand - the action is calculating that first and passing it 
on as null instead of adding a message. Once this is fixed, it looks 
fine at runtime - taking a look at the commits now.


I added the "Access to No Repositories" screen / message.
OK to go ahead with the merge?

- Joakim

Re: archiva-backend-security branch.

[Joakim Erdfelt]

There's nothing to present the "There are no repositories you have
access to" style message on the xwork side.
I should add that.

Also, the branch has the old embedded appserver.base antrun.
If you have a $HOME/.m2/archiva.xml + that embedded appserver.base
antrun, you'll have no repositories presented to you. nor any ability
for them to startup in default mode.

I understand the purpose of the embedded appserver.base antrun, but it
doesn't work in practice, some other things need to be fixed first. 
Maybe we should disable the embedded appserver.base antrun until we can
solve all the use-cases properly.

Brett suggested to me to specify the appserver.base on the command line
via the
-Dappserver.base=alternative/dir/to/the/your/custom/appserver/base but I
never got that to work.

- Joakim

Maria Odea Ching wrote:
> I've tried running the branch, but I got a 500 error when I clicked
> Browse after doing a repo scan.. this was the cause of the error I got:
>
> java.lang.IllegalArgumentException: Selected repositories cannot be
> null. at
> org.apache.maven.archiva.database.constraints.SqlBuilder.appendWhereSelectedRepositories(SqlBuilder.java:64)
> at
> org.apache.maven.archiva.database.constraints.UniqueGroupIdConstraint.(UniqueGroupIdConstraint.java:50)
> at
> org.apache.maven.archiva.database.browsing.DefaultRepositoryBrowsing.getRoot(DefaultRepositoryBrowsing.java:69)
> at
> org.apache.maven.archiva.web.action.BrowseAction.browse(BrowseAction.java:69)
>
>
> Is it just me or did anybody get this too?
>
> I also noticed that there were no default remote repositories and
> proxy connectors configured (both in trunk and branch). Is this the
> new setup? (Btw, I used jetty:run to run the webapp) :)
>
> Thanks,
> Deng
>
>
> Joakim Erdfelt wrote:
>> 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,
>>
>

Re: svn commit: r590908 [2/2] - in /maven/archiva/trunk: archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/ archiva-base/archiva-configuration/src/test/resources/

[Joakim Erdfelt]

Whoops.
Sorry about that.

Yep, it still gets in the way.
And I can't get the -Dappserver.base or -Dappserver.home on the build 
command line to ever take.


- Joakim

Brett Porter wrote:


On 01/11/2007, at 5:21 PM, [EMAIL PROTECTED] wrote:



Modified: maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml?rev=590908&r1=590907&r2=590908&view=diff 

== 


--- maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml (original)
+++ maven/archiva/trunk/archiva-web/archiva-webapp/pom.xml Wed Oct 31 
23:21:26 2007

@@ -420,6 +420,7 @@
   
 
   
+  
 
   
   



Looks like this slipped in - maybe it can be moved to a profile 
after-all and I can add it to my default profiles in the settings if 
it's that much of a pain?


- Brett

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




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

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

[Joakim Erdfelt]

Brett Porter wrote:

 (old)  IGNORED, ONCE, HOURLY, DAILY, DISABLED
 (proposed) ALWAYS, ONCE, HOURLY, DAILY, NEVER
Snapshots (for often to check for)

Releases (how often to check for)
 AS ABOVE

Cache-Failures
 (old)  IGNORED, CACHED
 (new) NO, YES
Checksum
 (old)  IGNORED, FIX, FAIL
 (new) IGNORE, FIX, FAIL

Hooray List!

New descriptions.

(for releases / snapshots policies)
ALWAYS : Means that the artifact is always updated from the remote repo.
ONCE : Means the artifact is updated only ever ONCE from the remote 
repo.  If it exists on the local repo, the remote repo is never hit for 
that artifact.
HOURLY : Means the artifact is updated from the remote repo, only if it 
is at least one hour old on the local repo.
DAILY : Means the artifact is updated from the remote repo, only if it 
is at least 1 day old on the local repo.

NEVER : Means the artifact is never updated from the remote repo.

(for cache-failures)
NO : Means that the existence of old failures is not checked.  All 
resource requests are allowed thru to the remote repo.
YES : Means that the existence of old failures is checked, and will 
prevent the request from being performed against the remote repo.


(for checksum)
IGNORE : Means the contents / validity of the checksum files is ignored.
FIX : Means that the checksum files are regenerated from the downloaded 
resources.
FAIL : Means that the checksum files are validated against the 
downloaded resource, if the resource does not pass the checksum 
validation, the resource and the checksum files are deleted from the 
local repository and a failure is issued for the transfer.


- Joakim

Re: svn commit: r590858 - in /maven/archiva/trunk/archiva-base: archiva-policies/src/main/java/org/apache/maven/archiva/policies/ archiva-policies/src/test/java/org/apache/maven/archiva/policies/ arch

[Joakim Erdfelt]

Brett Porter wrote:

Hi Joakim,

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

Fixing release / snapshot policies from applying tests on 
maven-metadata.xml files.


Was this the addition of the filetype property - or something else as 
well? Bit hard to find in the change :)


Yes. the filetype property.
Didn't want to pull in all of archiva-repository-layer just to get the 
benefits of metadata detection.
Felt i could just let the proxy handlers determine scope (artifact / 
metadata / supportfile) and pass it down the the policy handlers.




Switching from boolean return on .applyPolicy() to throwing 
exception, to gain better logging of why the transfer failed.


No need to change it now, but I don't really agree with this. I don't 
agree with using exceptions for non-exceptional conditions for 
readability reasons - particularly just to pass a string around. IMO, 
better alternatives:

1) just log in the policy check and return true/false as before
2) return an object that has a "success" flag and a "reason" string 
(essentially the same as an exception, but correctly using the return 
type)


The flaw with that is that only having a boolean doesn't tell us WHY 
something failed.
Also the log didn't make a distinction between config issue, normal 
happy path, informational, and problem path.

Since this is a failure, throw an exception.
Made the code easier to read too.  Lots of uncoding here.



 getLogger().debug( "Applying [" + key + "] policy with 
[" + setting + "]" );

-if ( !policy.applyPolicy( setting, request, localFile ) )
+try
 {
-getLogger().debug( "Didn't pass the [" + key + "] 
policy." );

-return false;
+policy.applyPolicy( setting, request, localFile );
+}
+catch ( PolicyConfigurationException e )
+{
+getLogger().error( e.getMessage(), e );
 }
 }


This is going to be very noisy if it's misconfigured - is there 
anything that can test these on system configuration so we can fail fast?
As for noise, the standard failure reasoning will easily be 
(10*(proxyConnector.size()) more noisy than the configuration errors.


Working on that now, the DefaultArchivaConfiguration.load() mechanism 
has many configuration cleanup / sanity things in it.
Shame you got rid of the ConfigurationCleanup interface a while back. 
would have made this easy to test individually instead of all lumped 
together like it is now.


Work on MRM-549 is proceeding.  Go comment on that other thread about 
SKIP/REJECT.
The change to that config.load() is due to MRM-549, but I'm cleaning up 
a ton of other proxy connector nonsense too.


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

Re: [VOTE] Release Archiva-1.0-beta-3 (Take 2)

[Joakim Erdfelt]

+1 lets do it!

- Joakim

Maria Odea Ching wrote:

Hi Everyone,

Take 2.. :)

Archiva 1.0-beta-3 is now ready for release.

The highlights of this release are:
- major fixes in path resolution of artifacts (for proxying and consumers)
- fixes in updating of metadata files
- fixes in proxying
- fixes in proxy connectors configuration
- tomcat deployment issues
- form validations in webapp

The bugs that were found from the previously prepared 1.0-beta-3 has also
been fixed.

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

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

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

http://people.apache.org/builds/maven/archiva/1.0-beta-3/


Everyone is encouraged to vote and give their feedback.

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

  

Re: [RESULTS] [VOTE] Release Archiva 1.0-beta-3 (Postpone the release)

[Joakim Erdfelt]

I say do it now, and start the vote now.
I've got a security related issue I'm working on now.
But I'd like to vet that for the 1.0-beta-4 release, not this 1.0-beta-3 
release.


- Joakim


Brett Porter wrote:
Any reason not to move forward now? (time permitting, of course :) 
Things seem to be ok at the moment... I'm using the current trunk and 
did a whole lot of building without a local repo with a mix of new and 
existing artifacts yesterday without issues (other than one or two 
non-blocking ones I fixed and/or filed already :).


Cheers,
Brett

On 30/10/2007, at 4:11 PM, Maria Odea Ching wrote:

I can do another release at the end of this week :) Everybody okay 
with that?


-Deng



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

Re: [jira] Created: (MRM-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/

[Joakim Erdfelt]

I want to start this work on monday, but I don't want to affect the 
re-vote on 1.0-beta-3.

So I can do this in a branch until the vote determination.

... and if you want to review it prior to merging into trunk.
It shouldn't take long to implement.  I predict about 2 days work.

- Joakim

Joakim Erdfelt wrote:

This shouldn't be a huge deal.
It would impact ...

1) Directory structure.
2) Build Heirarchy.
3) Browse component.
4) Search component.
5) Need for webapp to pass into Browse / Search components the 
security principle.


And that's it.
I moved these issues (all 5 related ones) to 1.0-beta-4 just to get a 
release out now.


It will _not_ impact ...
* The database.
* The configuration.
* Admin actions
* Repository Servlet.
* Consumers.

- Joakim

Brett Porter wrote:

Joakim,

How much disruption is this going to cause? I know we want to do this 
at some point, but if it turns into something big or risky, I'd 
rather we just put the security in the browse action for now and take 
this on in 1.1.


- Brett

On 27/10/2007, at 10:21 AM, Joakim Erdfelt (JIRA) wrote:


archiva-security/ needs to move from archiva-webapp/ to archiva-base/
-

 Key: MRM-570
 URL: http://jira.codehaus.org/browse/MRM-570
 Project: Archiva
  Issue Type: Task
  Components: Users/Security
Affects Versions: 1.0-beta-2
        Reporter: Joakim Erdfelt


Since we need to implement backend security around the browse 
(MRM-569) and search (MRM-516) facilities, the archiva-security 
module needs to be decoupled from archiva-webapp and brought into 
archiva-base for the general use of all archiva-base modules.


Leaving archiva-security like it is now will result in pulling in 
many webapp specific libraries and concepts that are not needed in 
the archiva-base heirarchy.



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





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







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

Re: [jira] Created: (MRM-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/

[Joakim Erdfelt]

This shouldn't be a huge deal.
It would impact ...

1) Directory structure.
2) Build Heirarchy.
3) Browse component.
4) Search component.
5) Need for webapp to pass into Browse / Search components the security 
principle.


And that's it.
I moved these issues (all 5 related ones) to 1.0-beta-4 just to get a 
release out now.


It will _not_ impact ...
* The database.
* The configuration.
* Admin actions
* Repository Servlet.
* Consumers.

- Joakim

Brett Porter wrote:

Joakim,

How much disruption is this going to cause? I know we want to do this 
at some point, but if it turns into something big or risky, I'd rather 
we just put the security in the browse action for now and take this on 
in 1.1.


- Brett

On 27/10/2007, at 10:21 AM, Joakim Erdfelt (JIRA) wrote:


archiva-security/ needs to move from archiva-webapp/ to archiva-base/
-

 Key: MRM-570
 URL: http://jira.codehaus.org/browse/MRM-570
 Project: Archiva
  Issue Type: Task
  Components: Users/Security
Affects Versions: 1.0-beta-2
    Reporter: Joakim Erdfelt


Since we need to implement backend security around the browse 
(MRM-569) and search (MRM-516) facilities, the archiva-security 
module needs to be decoupled from archiva-webapp and brought into 
archiva-base for the general use of all archiva-base modules.


Leaving archiva-security like it is now will result in pulling in 
many webapp specific libraries and concepts that are not needed in 
the archiva-base heirarchy.



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





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




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

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

[Joakim Erdfelt]

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]

21 Issues to go for 1.0-beta-4!

[Joakim Erdfelt]

I'd like to thank all of those that are living on the bleeding edge and 
helping us close the gap to 1.0!


Only 21 issues to go for 1.0-beta-4 (or hopefully we are so close we can 
call it 1.0-rc1)
Almost half of the issues are review of settings and defaults or 
documentation.
I've started 2 threads in archiva-dev with hopes of closing at least 3 
of them, but we need your help to review the rest.
We should be able to get these last few issues resolved within a week or 
two with your help.


--
- Joakim Erdfelt
 [EMAIL PROTECTED]

[MRM-185] revise logging granularity.

[Joakim Erdfelt]

I'd like to get a consensus from everyone on what the Release level 
logging defaults / guidelines should be.


Things like (just to get this started)...

log4j.xml settings:
 Archiva root at Info.
 JPOX at Warn.
 Database at Warn.
 Configuration at Warn.

And noisy or not noisy enough specific settings?
 Proxy requests should be detail WHY a download wasn't attempted 
(policy / whitelist / blacklist).

 Proxy success should be logged.

Once we have a set that we like, then we can implement it and close MRM-185.

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

Re: svn commit: r586858 - /maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml

[Joakim Erdfelt]

Brett Porter wrote:


On 22/10/2007, at 2:02 AM, Joakim Erdfelt wrote:


Can you wrap this into a profile?


I thought about that, but the idea is to have it by default so that if 
I forget an option I get a sensible default. Otherwise, I accidentally 
hose my actual "production" install on the same machine by the 
appearance of ~/.m2/archiva.xml



Like we do for the mysql / postgres options?
This makes testing large repositories rather difficult, as I have to 
reconfigure every time now.


I use -Dappserver.base=/path/to/other-install, but only when I need to 
test the other data. Do you need to test a large repository every time 
you test the webapp?


This doesn't work.
It loads both files resulting in a "Configuration can not be saved when 
it is loaded from two sources" error when loaded this way ...


[archiva-webapp]$ mvn -Dappserver.base=$HOME/java/archiva clean jetty:run

The $HOME/java/archiva directory has a conf, log, and repos, subdirectory.
The $HOME/java/archiva/conf/archiva.xml file contains my desired 
configuration.




It also appears that this is showing up in the standalone plexus 
application, making user level configuration impossible that way too.


I'm not sure what you are referring to here?

I'm happy to roll it back if it's inconveniencing anyone else, I just 
wanted to go for the safer option by default.


See my recent note on the 1.0-beta-3 release.
Still tracking down what files it thinks it has loaded.

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

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

[Joakim Erdfelt]

I get a "Configuration can not be saved when it is loaded from two 
sources" error when I use this standalone build.

I can't get any of the admin screens to work.

Works OK if I use the war file on tomcat tho. (Wow! what a difference 
from a month ago)


- Joakim

Maria Odea Ching wrote:

Hi All,

Archiva 1.0-beta-3 is now ready for release.

The highlights of this release are:
- major fixes in path resolution of artifacts (for proxying and consumers)
- fixes in updating of metadata files
- fixes in proxy connectors configuration
- tomcat deployment issues
- additional fixes in proxying
- form validations in webapp

The release notes for Archiva 1.0-beta-3 is available here:

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


While the binaries including the sources, checksums and signatures can be
found in:

http://people.apache.org/builds/maven/archiva/1.0-beta-3/<http://people.apache.org/builds/maven/archiva/1.0-beta-2/>

Everyone is encouraged to vote and give their feedback.

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


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


Here's my +1


Thanks,
Deng

  



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

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

[Joakim Erdfelt]

MRM-560 : Dependency Tree causes an Exception
MRM-561 : Error 500 while deleting a proxy connector

Those are the ones.

- Joakim

Wendy Smoak wrote:

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

This release has a few exceptions visible to the user. (MRM-560, MRM-561)
Should we fix these, and wait on 1.0-beta-3? or just make 1.0-beta-4
come out quickly after 1.0-beta-3?



I don't think it's a good idea to "re-do" builds after they are tagged
and made available to download for testing.

We could decide not to officially release it, but on the surface those
two issues don't seem serious enough to me.  (Error on the dependency
tree web page, and overzealous logging?)

  



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

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

[Joakim Erdfelt]

This release has a few exceptions visible to the user. (MRM-560, MRM-561)
Should we fix these, and wait on 1.0-beta-3? or just make 1.0-beta-4 
come out quickly after 1.0-beta-3?


- Joakim

Maria Odea Ching wrote:

Hi All,

Archiva 1.0-beta-3 is now ready for release.

The highlights of this release are:
- major fixes in path resolution of artifacts (for proxying and consumers)
- fixes in updating of metadata files
- fixes in proxy connectors configuration
- tomcat deployment issues
- additional fixes in proxying
- form validations in webapp

The release notes for Archiva 1.0-beta-3 is available here:

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


While the binaries including the sources, checksums and signatures can be
found in:

http://people.apache.org/builds/maven/archiva/1.0-beta-3/<http://people.apache.org/builds/maven/archiva/1.0-beta-2/>

Everyone is encouraged to vote and give their feedback.

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


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


Here's my +1


Thanks,
Deng

  



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

Re: svn commit: r586858 - /maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml

[Joakim Erdfelt]

Can you wrap this into a profile?
Like we do for the mysql / postgres options?
This makes testing large repositories rather difficult, as I have to 
reconfigure every time now.
It also appears that this is showing up in the standalone plexus 
application, making user level configuration impossible that way too.


- Joakim

[EMAIL PROTECTED] wrote:

Author: brett
Date: Sat Oct 20 22:20:38 2007
New Revision: 586858

URL: http://svn.apache.org/viewvc?rev=586858&view=rev
Log:
add a configuration file for jetty:run so that it doesn't create 
~/.m2/archiva.xml - make testing isolated

Added:

maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml
   (with props)

Added: 
maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml
URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml?rev=586858&view=auto
==
--- 
maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml
 (added)
+++ 
maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml
 Sat Oct 20 22:20:38 2007
@@ -0,0 +1,169 @@
+
+
+  2
+  
+
+  internal
+  Archiva Managed Internal Repository
+  ${appserver.base}/data/repositories/internal
+  default
+  true
+  false
+  true
+  0 0 0 * * ?
+  30
+
+
+  snapshots
+  Archiva Managed Snapshot Repository
+  ${appserver.base}/data/repositories/snapshots
+  default
+  false
+  true
+  true
+  0 0\,30 0 * * ?
+  30
+
+  
+  
+
+  central
+  Central Repository
+  http://repo1.maven.org/maven2
+  default
+
+
+  maven2-repository.dev.java.net
+  Java.net Repository for Maven 2
+  http://download.java.net/maven/2/
+  default
+
+  
+
+  
+
+  internal
+  central
+  
+  
+disabled
+once
+fix
+cached
+  
+  
+**/*
+  
+
+
+  internal
+  maven2-repository.dev.java.net
+  
+  
+disabled
+once
+fix
+cached
+  
+  
+javax/**
+  
+
+  
+
+  
+
+  
+artifacts
+
+  **/*.pom
+  **/*.jar
+  **/*.ear
+  **/*.war
+  **/*.car
+  **/*.sar
+  **/*.mar
+  **/*.rar
+  **/*.dtd
+  **/*.tld
+  **/*.tar.gz
+  **/*.tar.bz2
+  **/*.zip
+
+  
+  
+indexable-content
+
+  **/*.txt
+  **/*.TXT
+  **/*.block
+  **/*.config
+  **/*.pom
+  **/*.xml
+  **/*.xsd
+  **/*.dtd
+  **/*.tld
+
+  
+  
+auto-remove
+
+  **/*.bak
+  **/*~
+  **/*-
+
+  
+  
+ignored
+
+  **/.htaccess
+  **/KEYS
+  **/*.rb
+  **/*.sh
+  **/.svn/**
+  **/.DAV/**
+
+  
+
+
+  update-db-artifact
+  create-missing-checksums
+  
update-db-repository-metadata
+  validate-checksum
+  validate-signature
+  index-content
+  auto-remove
+  auto-rename
+  metadata-updater
+  
+
+
+  update-db-bad-content
+
+  
+
+  
+0 0 0 * * ?
+
+  index-artifact
+  update-db-project
+  validate-repository-metadata
+  index-archive-toc
+  update-db-bytecode-stats
+  index-public-methods
+
+
+  not-present-remove-db-artifact
+  not-present-remove-db-project
+  not-present-remove-indexed
+
+  
+
+  
+
+  true
+  true
+
+  
+
+

Propchange: 
maven/archiva/trunk/archiva-web/archiva-webapp/src/appserver-base/conf/archiva.xml
--
svn:eol-style = native


  



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

Re: svn commit: r586635 - in /maven/archiva/trunk/archiva-web/archiva-webapp/src: main/java/org/apache/maven/archiva/web/action/admin/repositories/ test/java/org/apache/maven/archiva/web/action/admin/

[Joakim Erdfelt]

Well, you do have a point there.
If the passed in repoId matches on either a sourceId or a targetId, then 
the proxy connector should be deleted.

wdyt?

- Joakim

Brett Porter wrote:
ugh, I obviously need new eyes. two times in a row I've read the 
variables back to front :D


On 20/10/2007, at 6:41 PM, Brett Porter wrote:


pass the repo id in as a parameter?

It's not a lot of code, no big deal, it's just that I noticed the 
other was already factored into a method and these classes had 
recently been emphasised as needing to share more code :)


- Brett

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


You'd think so, but the rule is different.
One removes based on connector.sourceId and the other removes based 
on connector.targetId
Guess I could bring out the commons-collection's Predicates again to 
make a common base method. ;-)


- Joakim

Brett Porter wrote:


On 20/10/2007, at 8:48 AM, [EMAIL PROTECTED] wrote:

+// [MRM-520] Proxy Connectors are not deleted with the 
deletion of a Repository.
+List proxyConnectors = 
getProxyConnectors();
+for ( ProxyConnectorConfiguration proxyConnector : 
proxyConnectors )

+{
+if ( StringUtils.equals( 
proxyConnector.getSourceRepoId(), cleanupRepository.getId() ) )

+{
+
archivaConfiguration.getConfiguration().removeProxyConnector( 
proxyConnector );

+}
+}


Shouldn't this duplication be in the common base class?

- Brett

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




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


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


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




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

Re: svn commit: r586635 - in /maven/archiva/trunk/archiva-web/archiva-webapp/src: main/java/org/apache/maven/archiva/web/action/admin/repositories/ test/java/org/apache/maven/archiva/web/action/admin/

[Joakim Erdfelt]

You'd think so, but the rule is different.
One removes based on connector.sourceId and the other removes based on 
connector.targetId
Guess I could bring out the commons-collection's Predicates again to 
make a common base method. ;-)


- Joakim

Brett Porter wrote:


On 20/10/2007, at 8:48 AM, [EMAIL PROTECTED] wrote:

+// [MRM-520] Proxy Connectors are not deleted with the 
deletion of a Repository.
+List proxyConnectors = 
getProxyConnectors();
+for ( ProxyConnectorConfiguration proxyConnector : 
proxyConnectors )

+{
+if ( StringUtils.equals( 
proxyConnector.getSourceRepoId(), cleanupRepository.getId() ) )

+{
+
archivaConfiguration.getConfiguration().removeProxyConnector( 
proxyConnector );

+}
+}


Shouldn't this duplication be in the common base class?

- Brett

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




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

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]

a-repository-layer/src/test/resources/m1-repo-filelist.txt?rev=583412&view=auto 

== 

--- 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/resources/m1-repo-filelist.txt 
(added)
+++ 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/resources/m1-repo-filelist.txt 
Wed Oct 10 02:47:20 2007

@@ -0,0 +1,6230 @@
+# Directory listing from people.apache.org
+# of path /www/people.apache.org/repo/m1-ibiblio-rsync-repository
+# Taken September 9, 2007
+#
+# File listing has been filtered using the following sed command.
+#
+#   sed -e "/\.md5$/d" -e "/\.sha1$/d" -e "/\.asc$/d" -e "/\.meta$/d" \
+#   -e "/LICENSE/d" -e "/\/licenses\//d"
+#
+# Any entries in here that are blatently wrong should be deleted.
+#


This is interesting as a one off, but not something I think we should 
be running in the unit tests. It's way too huge.


I think this is important to test the effectiveness of the layout routines.
And it doesn't take that long.
Course, you can't see that as I apparently haven't checked in that unit 
test.  ;-)

Lemme see if I can find that on my laptop backup cd and get that commit'd.

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

Re: svn commit: r583862 - /maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java

[Joakim Erdfelt]

ath() );

-hasFetched = true;
+metadataNeedsUpdating = true;
 }
 }

-if ( hasFetched || fileExists( localFile ) )
+if ( hasBeenUpdated( localFile, originalTimestamp ) )
+{
+metadataNeedsUpdating = true;
+}
+
+if ( metadataNeedsUpdating )
 {
 try
 {
@@ -428,7 +459,6 @@

 transferChecksum( wagon, remoteRepository, 
remotePath, localFile, ".sha1" );
 transferChecksum( wagon, remoteRepository, 
remotePath, localFile, ".md5" );

-
 }
 }
 catch ( ResourceDoesNotExistException e )



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

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

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



Wendy Smoak wrote:

I'm looking at...
http://maven.apache.org/archiva/ref/latest/apidocs/org/apache/maven/archiva/consumers/package-summary.html

What's the difference between ArchivaArtifactConsumer and
RepositoryContentConsumer?  (When is an artifact not considered
repository content?)
  


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

Re: svn commit: r584986 - /maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java

[Joakim Erdfelt]

I traced this bug down to the the plexus-webdav code to this line.

this.base.lookup( resource ).toAsciiString();

base is a URI object, resource is the relative path (String) to the 
resource.

At first look, this appears to be a bug in the java.net.URI object!!
(or at least an unexpected response from that object)

It was easier to put the logic on the archiva side.
Also, we can use the work from MRM-490 to make this a more pretty error. ;-)

- Joakim

Brett Porter wrote:
This couldn't be fixed in the webdav library, since there are related 
changes being made there already?


Cheers,
Brett

On 16/10/2007, at 8:52 AM, [EMAIL PROTECTED] wrote:


Author: joakime
Date: Mon Oct 15 17:52:42 2007
New Revision: 584986

URL: http://svn.apache.org/viewvc?rev=584986&view=rev
Log:
[MRM-468] incorrect URL reported from failures in WebDAV
Corrected locally the error message being reported by it.could.webdav


Modified:

maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java 



Modified: 
maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java 

URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java?rev=584986&r1=584985&r2=584986&view=diff 

== 

--- 
maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java 
(original)
+++ 
maven/archiva/trunk/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/repository/ProxiedDavServer.java 
Mon Oct 15 17:52:42 2007

@@ -46,6 +46,7 @@
 import java.io.FileNotFoundException;
 import java.io.FileReader;
 import java.io.IOException;
+import java.io.PrintWriter;

 import javax.servlet.ServletConfig;
 import javax.servlet.ServletException;
@@ -161,7 +162,64 @@

 // TODO: [MRM-524] determine http caching options for other 
types of files (artifacts, sha1, md5, snapshots)


-davServer.process( request, response );
+if( resourceExists( request ) )
+{
+davServer.process( request, response );
+}
+else
+{
+respondResourceMissing( request, response );
+}
+}
+
+private void respondResourceMissing( DavServerRequest request, 
HttpServletResponse response )

+{
+response.setStatus( HttpServletResponse.SC_NOT_FOUND );
+
+try
+{
+StringBuffer missingUrl = new StringBuffer();
+missingUrl.append( request.getRequest().getScheme() 
).append( "://" );
+missingUrl.append( request.getRequest().getServerName() 
).append( ":" );

+missingUrl.append( request.getRequest().getServerPort() );
+missingUrl.append( request.getRequest().getServletPath() );
+// missingUrl.append( request.getRequest().getPathInfo() );
+
+String message = "Error 404 Not Found";
+
+PrintWriter out = new PrintWriter( 
response.getOutputStream() );

+
+response.setContentType( "text/html; charset=\"UTF-8\"" );
+
+out.println( "" );
+out.println( "" + message + 
"" );

+out.println( "" );
+
+out.print( "" );
+out.print( message );
+out.println( "" );
+
+out.print( "The following resource does not exist: href=\"" );

+out.print( missingUrl.toString() );
+out.println( "\">" );
+out.print( missingUrl.toString() );
+out.println( "" );
+
+out.println( "" );
+
+out.flush();
+}
+catch ( IOException e )
+{
+e.printStackTrace();
+}
+}
+
+private boolean resourceExists( DavServerRequest request )
+{
+String resource = request.getLogicalResource();
+File resourceFile = new File( 
managedRepository.getRepoRoot(), resource );

+return resourceFile.exists();
 }

 private void fetchContentFromProxies( DavServerRequest request )



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




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

Re: svn commit: r584735 - in /maven/archiva/trunk: archiva-base/archiva-consumers/archiva-database-consumers/src/main/java/org/apache/maven/archiva/consumers/database/ archiva-base/archiva-consumers/a

[Joakim Erdfelt]

Maria Odea Ching wrote:

Brett Porter wrote:

Hi Deng,

On 15/10/2007, at 7:16 PM, [EMAIL PROTECTED] wrote:


[MRM-37 and MRM-527]
- added code for cleaning up the database of artifacts that are no 
longer existing in the repository
(DatabaseCleanupRemoveArtifactConsumer and 
DatabaseCleanupRemoveProjectConsumer)

- created tests for database cleanup of removed artifacts
- updated some of the test cases (in archiva-database and 
archiva-scheduled modules) to reflect the changes in thedb cleanup 
consumers


Cool - looks good. A couple of quick questions :)


+ /**
+ * @plexus.requirement
+ */
+ private BidirectionalRepositoryLayoutFactory layoutFactory;
+
+ /**
+ * @plexus.requirement
+ */
+ private RepositoryContentFactory repositoryFactory;
+


I'm probably wrong, but I understood the content factory should be 
used instead of the layoutFactory - does it provide a way to do this 
instead, or did I misunderstand?




I think the content factory only provides the repository configuration 
while the layout factory provides a means of getting the layout 
(BidirectionalRepositoryLayout) of the repository where the artifact 
is located and converting the path from the given artifact. I needed 
the content factory to get the repository url and the layout factory 
for the artifact path so I could get the absolute path to the actual 
artifact and check if it still exists. :)


BidirectionalRepositoryLayout is going away.
They are broken.
They do not work.
They will not be fixed.
They encourage shortcuts (which is bad).
Shortcuts encourage bugs (which is also bad).
Bad code is ... uhm ... bad (which is also also bad).  ;-)

Use the repositoryFactory.getManagedRepository(repoId) to get a 
ManagedRepositoryContent object.
Then use the .toFile() .toPath() .toArtifactReference() methods in 
there.  They should have the same method signature that you are familiar 
with in the old BidirectionalRepositoryLayout classes.


I want to encourage operations against the repository to utilize those 
objects, we have plenty of find/get methods already, and we even a 
.deleteVersion(VersionedReference) method in there too.  If you can 
think of more, let me know.


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

Re: Unable to run Archiva r584279

[Joakim Erdfelt]

I don't understand how this became a problem for Wendy.
I'm using the standalone runtime right now.
And it doesn't have the jstl-api inside of the WEB-INF/lib

- Joakim

Brett Porter wrote:
> I reopened MRM-459 (r584218), which would have done this, and added a
> comment.
>
> On 14/10/2007, at 4:48 AM, Wendy Smoak wrote:
>
>> Is anyone else seeing this?  At r584279, the app starts up but I get
>> this when it tries to display the page to add the Admin user:
>>
>> INFO   | jvm 1| 2007/10/13 13:41:10 | WARNING:
>> /archiva/security/addadmin.action:
>> INFO   | jvm 1| 2007/10/13 13:41:10 |
>> java.lang.NoClassDefFoundError:
>> javax/servlet/jsp/jstl/core/ConditionalTagSupport
>> INFO   | jvm 1| 2007/10/13 13:41:10 |   at
>> java.lang.ClassLoader.defineClass1(Native Method)
>> INFO   | jvm 1| 2007/10/13 13:41:10 |   at
>> java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>> INFO   | jvm 1| 2007/10/13 13:41:10 |   at
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>> INFO   | jvm 1| 2007/10/13 13:41:10 |   at
>> java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>> INFO   | jvm 1| 2007/10/13 13:41:10 |   at
>> java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>>
>> -- 
>> Wendy
>
> -- 
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>

Re: svn commit: r584279 - in /maven/archiva/trunk/archiva-web: archiva-security/src/main/java/org/apache/maven/archiva/security/ archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/

[Joakim Erdfelt]

I can only think of 1 place for this.
When DefaultArchivaConfiguration loads the default-archiva.xml from its 
resources location and puts it into place.


Catch is, it will require pulling in redback-rbac all the way down to 
archiva-configuration.
Which means archiva-security will likely go away (merged with 
archiva-configuration), with the RoleManager work that Jesse did, it was 
inevitable for the archiva-security to go away.
But wait! there's more! Because of our use of a role with a resource, 
that means we have to pull in RbacManager too. (because RoleManager 
doesn't support that kind of assignment yet, see Jesse & Redback 
1.0-alpha-4 work)
Also, it means that every unit test that uses the 
DefaultArchivaConfiguration object will have to pull in the RoleManager, 
and RBACManager too.
And while we are loading those, we'll either need to configure a 
database everywhere, or use the "memory" role manager to avoid using the 
database.
Which in turn means that all of those component xmls everywhere will 
need to be touched, which at last count,


Big commit coming?
(back of the envelope math)
$ find . -name "*.xml" -exec grep -l DefaultArchivaConfiguration {} \; | 
wc -l

27
$ find . -name "*.xml" -exec grep -n DefaultArchivaConfiguration {} \; | 
wc -l

63

27 files, 63 usages of DefaultArchivaConfiguration.
Average of about 65 new lines needed per DefaultArchivaConfiguration 
definition.

65 * 63 = 4095 lines.
+ 27% diff overhead = 5200 lines

That should be a 4 part commit (once split by apache's commit message 
email split routines)

And that's the bare minimum work.
It's likely that archiva-security goes away, and archiva-configuration 
gains a bunch of security.


Ready for it?

- Joakim

Wendy Smoak wrote:

On 10/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
  

Author: joakime
Date: Fri Oct 12 14:35:41 2007
New Revision: 584279

URL: http://svn.apache.org/viewvc?rev=584279&view=rev
Log:
[MRM-398] configure guest access by default for pre-configured repositories
Newly added repositories are assigned to the guest user in read-only mode.



As mentioned on the issue comments, this isn't what was requested.
Brett and I both want a way to pre-configure guest access "out of the
box" for pre-configured repositories.

I don't think it's a good idea to make newly added repositories
visible by default.

  



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

Re: svn commit: r583630 - /maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java

[Joakim Erdfelt]

You are right, it doesn't work.
I can still get double repositories in the RepositoriesAction via the 
web browser.
And that line will not remove the double repositories. Added unit test 
to show that.
Open up 
archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/ArchivaConfigurationTest.java
and check out the /* commented */ XMLAssert's at the bottom of the 
.testAutoDetectV1() method.


- Joakim

Brett Porter wrote:

Can you add a test to verify this?

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


Author: joakime
Date: Wed Oct 10 15:15:51 2007
New Revision: 583630

URL: http://svn.apache.org/viewvc?rev=583630&view=rev
Log:
Eliminating duplicate repositories from showing up after the conversion.

Modified:

maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java 



Modified: 
maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java 

URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java?rev=583630&r1=583629&r2=583630&view=diff 

== 

--- 
maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java 
(original)
+++ 
maven/archiva/trunk/archiva-base/archiva-configuration/src/main/java/org/apache/maven/archiva/configuration/DefaultArchivaConfiguration.java 
Wed Oct 10 15:15:51 2007

@@ -88,7 +88,7 @@
  * Configuration Listeners we've registered.
  */
 private Set listeners = new 
HashSet();

-
+
 /**
  * Registry Listeners we've registered.
  */
@@ -153,6 +153,9 @@
 config.addRemoteRepository( repo );
 }
 }
+
+// Prevent duplicate repositories from showing up.
+config.getRepositories().clear();
 }

 // Normalize the order fields in the proxy connectors.
@@ -255,7 +258,7 @@

 new ConfigurationRegistryWriter().write( configuration, 
section );

 section.save();
-
+
 triggerEvent( ConfigurationEvent.SAVED );

 this.configuration = processExpressions( configuration );
@@ -278,8 +281,8 @@
 try
 {
 ( (Initializable) registry ).initialize();
-
-for ( RegistryListener regListener: registryListeners )
+
+for ( RegistryListener regListener : registryListeners )
 {
 addRegistryChangeListener( regListener );
 }
@@ -288,7 +291,7 @@
 {
 throw new RegistryException( "Unable to reinitialize 
configuration: " + e.getMessage(), e );

 }
-
+
 triggerEvent( ConfigurationEvent.SAVED );

 return registry.getSection( KEY + ".user" );
@@ -329,7 +332,7 @@

 listeners.remove( listener );
 }
-
+
 public void addChangeListener( RegistryListener listener )
 {
 addRegistryChangeListener( listener );
@@ -351,7 +354,6 @@
 section.addChangeListener( listener );
 }
 }
-

 public void initialize()
 throws InitializationException



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




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

Re: What happened to the Archiva CI builds?

[Joakim Erdfelt]

Ah makes sense.

Guess I was having a "its too quiet in here" nervous moment. ;-)
(seen too many Clint Eastwood westerns lately)

- Joakim

Brett Porter wrote:
It's not set to notify on success - last successful build was at 11am 
+, as expected:


http://maven.zones.apache.org/continuum/component/buildResults.action?projectId=297&projectGroupId=8 



- Brett

On 11/10/2007, at 4:56 PM, Joakim Erdfelt wrote:

I've been missing the archiva ci build notifications for the past 48 
hours.

Is it still running?

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


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




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

What happened to the Archiva CI builds?

[Joakim Erdfelt]

I've been missing the archiva ci build notifications for the past 48 hours.
Is it still running?

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

Re: svn commit: r583632 - /maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java

[Joakim Erdfelt]

I stay away from File.getCanonicalPath() as it has burned me too many 
times in the past.
I've seen different implementations of this method to include full 
absolute path on some JVMs, and other times only the path that you 
passed in.


- Joakim

Brett Porter wrote:

would "new File( path ).getCanonicalPath()" be more suitable?

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


Author: joakime
Date: Wed Oct 10 15:23:04 2007
New Revision: 583632

URL: http://svn.apache.org/viewvc?rev=583632&view=rev
Log:
[MRM-534] Test failure in RepositoryContentConsumerUtilTest
Fixed OS specific validation in mock object to be OS neutral.

Modified:

maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java 



Modified: 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java 

URL: 
http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java?rev=583632&r1=583631&r2=583632&view=diff 

== 

--- 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java 
(original)
+++ 
maven/archiva/trunk/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/scanner/RepositoryContentConsumerUtilTest.java 
Wed Oct 10 15:23:04 2007

@@ -19,6 +19,7 @@
  * under the License.
  */

+import org.apache.commons.lang.SystemUtils;
 import 
org.apache.maven.archiva.configuration.ManagedRepositoryConfiguration;
 import 
org.apache.maven.archiva.consumers.InvalidRepositoryContentConsumer;
 import 
org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer;

@@ -27,6 +28,8 @@
 import org.codehaus.plexus.PlexusTestCase;
 import org.easymock.MockControl;

+import com.sun.corba.se.impl.encoding.OSFCodeSetRegistry;
+
 import java.io.File;
 import java.util.Collections;
 import java.util.List;
@@ -121,13 +124,13 @@

 ManagedRepositoryConfiguration repo = createRepository( 
"id", "name", getTestFile( "target/test-repo" ) );
 File testFile = getTestFile( 
"target/test-repo/path/to/test-file.txt" );

-
+
 knownConsumer.beginScan( repo );
 knownConsumer.getExcludes();
 knownControl.setReturnValue( Collections.EMPTY_LIST );
 knownConsumer.getIncludes();
 knownControl.setReturnValue( Collections.singletonList( 
"**/*.txt" ) );

-knownConsumer.processFile( "path/to/test-file.txt" );
+knownConsumer.processFile( _OS("path/to/test-file.txt") );
 //knownConsumer.completeScan();
 knownControl.replay();

@@ -154,7 +157,7 @@
 knownControl.replay();

 invalidConsumer.beginScan( repo );
-invalidConsumer.processFile( "path/to/test-file.xml" );
+invalidConsumer.processFile( _OS("path/to/test-file.xml") );
 invalidConsumer.getId();
 invalidControl.setReturnValue( "invalid" );
 //invalidConsumer.completeScan();
@@ -177,7 +180,7 @@
 knownControl.replay();

 invalidConsumer.beginScan( repo );
-invalidConsumer.processFile( "path/to/test-file.txt" );
+invalidConsumer.processFile( _OS("path/to/test-file.txt") );
 invalidConsumer.getId();
 invalidControl.setReturnValue( "invalid" );
 //invalidConsumer.completeScan();
@@ -187,5 +190,18 @@

 knownControl.verify();
 invalidControl.verify();
+}
+
+/**
+ * Create an OS specific version of the filepath.
+ * Provide path in unix "/" format.
+ */
+private String _OS( String path )
+{
+if ( SystemUtils.IS_OS_WINDOWS )
+{
+    return path.replace( '/', '\\' );
+}
+return path;
 }
 }



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




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

Monster Commit Breakdown - svn commit: r583412 [1/8]

[Joakim Erdfelt]

subject to failure in real world scenarios.

 As we get more and more users of Archiva for their day to day projects,
 we see more and more examples of legitimate usage of Archiva where the
 most basic functions fail due to a one layout assumption or another.

 The jist of the commit is to eliminate the possibility of failure by
 removing the ability to take shortcuts in the code.

 There was also plenty of uncoding done here to join together the
 various implementations of finding versions, or related files,
 or updating metadata.

 (2) I could have split this commit up into separate pieces, but decided
 that getting this code into place was more important that spending the
 next several days carefully crafting the optimum separation of commits
 to perform that wouldn't break the build, or have a dependency on another
 commit coming up.  This was my decision, I was not coerced into it, I
 weighed the options (3) and felt that getting a version 1.0 out sooner
 rather than later was more important. 


 I would love to see Archiva 1.0 final out before ApacheCon US
 (starting on November 10th, 2007)

 This code is a bug fix for current open and assigned jiras, it is not
 a rearchitecting, or work against future issues, or even an attempt at
 code perfection.

 Archiva is a web application, and as such, will have a different way
 of handling changes to the codebase, it is not subject to the the same
 stringent commit and change controls in place for maven, or java libs,
 or components that are either released, shared, or in common use across
 many users or other applications.  This is the best time to make these
 kind of changes, before the release, before the web services.

 I acknowledge that I could have branched this, which given the flak i'm
 getting for this commit, I probably should have.  But I stand by this
 change as a means to get the product stable in a faster fashion.

 I apologize for scaring the crap out of the other devs.
 I apologize for for not making a branch first.
 I apologize for not splitting up the commit.
 I apologize for stomping across other peoples active work.

 In the future I promise to be more clear about the scope of changes
 that need to be done.

 I promise to better manage my commit sizes and scope in the future.

 Hopefully, this has addressed any concerns about this monster commit.

 If not, please, by all means, SAY SOMETHING. ;-)

 In the end, I'm sure every developer and commitor for Archiva will
 appreciate this change for what it is.

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

Re: [Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

It works! yay!
And there was much rejoicing...

nicolas,
Check out the new RepositoryRequest object, and ManagedRepositoryContent 
structure inside of archiva-repository-layer.


There's plenty of unit tests to show that they work.

Its late for me, I'm going to get some sleep and expand on this (or 
reply to all of Brett's questions) when I get up.


- Joakim

Brett Porter wrote:
Joakim seems to be indicating he'll finish something already today, so 
we should probably take a look at that and go from there.


- Brett

On 10/10/2007, at 7:20 AM, nicolas de loof wrote:


I'd suggest a "merge" of 2 options :

1 . have an exception list, used by the LegacyBidirectionalLayout to 
resolve
those artifactIds, maybe stored in the archiva DB or in a file (I've 
never

used jpox, so can't say if it's simple to do)

2 . add an optional ArtifactReferenceVerifier as param of
toArtifactReference(path) :

public interface ArtifactReferenceVerifier
{
boolean isValidReference( ArtifactReference ref );
}

3 . make the BidirectionalLegacyLayout build the default
[artifactId:version:classifier] and check for validity. If not, build 
all

possible combinations and test them until getting a valid one. Store the
result in exceptions (cache).

4 . From the DavProxyServlet, pass a verifier that check for the file to
exists in any proxied repo.
In other place, pass null. The artifact used is allready in the 
managed repo

so is allready registered as an exception if required.

Using this, we can provide a default exception list for known issues 
from

central, and also provide with fiew changes a deterministic
LegacyBidirectionalLayout with auto-enhancement of the exception list.

Nico.




2007/10/9, Brett Porter <[EMAIL PROTECTED]>:


Hi Nicolas,

Thanks for the summary - it sounds spot on. Just one clarification:

On 09/10/2007, at 5:25 PM, nicolas de loof wrote:


Brett suggest to have a dedicated UI to maintain a set of
exceptions. That
would be a way to force the LegacyBidirectionalLayout to be
deterministic.
This option has less impact on archiva design, but requires
- a new web UI
- some work for the repository manager


I actually suggested the simplest possible route here - I think if
these can be handled via a configuration file that is enough as we
shoul be able to pre-specify the vast majority of the exceptions
based on the rules for central.

What is your opinion on the best way forward?

Thanks,
Brett

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



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




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

Re: svn commit: r582987 [1/3] - in /maven/archiva/trunk: archiva-base/archiva-consumers/archiva-consumer-api/ archiva-base/archiva-consumers/archiva-consumer-api/src/main/java/org/apache/maven/archiva

[Joakim Erdfelt]

Good questions.
I think I'm genetically predisposed to short commit messages.

a) Replacing ArchivaRepository with appropriate configuration object (be 
it managed or remote)

b) Due to filed bugs...
   * Ones surrounding updating of the configuration and not seeing the 
change active.

  The duality of repositories presented bad usages.
  Updates in the configuration wasn't propogated to those 
components that used the ArchivaRepository.
  Bad local references to ArchivaRepository objects that were no 
longer valid. etc...

   * Ones surrounding the metadata updates.
  There is 3 places in the code that updates metadata now.
  Need to merge these pieces of code together.
   * Bad usage of Layouts in the consumers, ignoring layout rules.
  This is the old C/C++ pattern.  Give someone a simple "out" and 
they take it, not realizing the implications.
  Well, the layout utils were a juicy "out" that caused bad code, 
bad assumptions, and bad handling.
c) Taking the layout utils and wrapping them away (so that they can't be 
abused) inside of a RepositoryContent object makes the use of a 
repository more reliable.  No more shortcuts available to the consumers.


- Joakim

Brett Porter wrote:

I haven't reviewed this commit in detail, but can you explain:

a) what actuallly changed (is this *just* replacing ArchivaRepository 
instances with relevant configuration objects?)
b) why was this needed? (I very deliberately didn't make this change 
when I made the other changes)
c) why does the other detection proposal depend on it? (I know I'm 
dragging my feet on responding, but I have started reviewing the work)


- Brett

On 09/10/2007, at 12:07 AM, [EMAIL PROTECTED] wrote:


Author: joakime
Date: Mon Oct  8 15:07:39 2007
New Revision: 582987

URL: http://svn.apache.org/viewvc?rev=582987&view=rev
Log:
Finishing the Repository split work that brett started.
ArchivaRepository has been removed from model.
This work was needed before repository layout/detection proposal work 
is started.




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




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

Re: svn commit: r578266 - in /maven/archiva/trunk/archiva-base/archiva-xml-tools/src/main/java/org/apache/maven/archiva/xml: XMLReader.java XMLWriter.java

[Joakim Erdfelt]

n/archiva/xml/XMLWriter.java?rev=578266&r1=578265&r2=578266&view=diff 

== 

--- 
maven/archiva/trunk/archiva-base/archiva-xml-tools/src/main/java/org/apache/maven/archiva/xml/XMLWriter.java 
(original)
+++ 
maven/archiva/trunk/archiva-base/archiva-xml-tools/src/main/java/org/apache/maven/archiva/xml/XMLWriter.java 
Fri Sep 21 13:46:15 2007

@@ -36,16 +36,32 @@
 public static void write( Document doc, Writer writer )
 throws XMLException
 {
+org.dom4j.io.XMLWriter xmlwriter = null;
+
 try
 {
 OutputFormat outputFormat = 
OutputFormat.createPrettyPrint();
-org.dom4j.io.XMLWriter xmlwriter = new 
org.dom4j.io.XMLWriter( writer, outputFormat );
+xmlwriter = new org.dom4j.io.XMLWriter( writer, 
outputFormat );

 xmlwriter.write( doc );
 xmlwriter.flush();
 }
 catch ( IOException e )
 {
 throw new XMLException( "Unable to write xml contents 
to writer: " + e.getMessage(), e );

+}
+finally
+{
+if( xmlwriter != null )
+{
+try
+{
+xmlwriter.close();
+}
+catch ( IOException e )
+{
+/* quietly ignore */
+}
+}
 }
 }
 }



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


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




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

Re: [Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

Brett Porter wrote:


On 09/10/2007, at 4:30 PM, Joakim Erdfelt wrote:


I think you are missing the core point of the proposal.

(Is nicolas the only one that understands the difficulty?)


No, I get it. I've been there before, several times, remember :)



Using *just* the path information, how do you get from a maven 1 
request to an artifact reference?

(groupId, artifactId, version, type)

ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
maven/jars/maven-test-plugin-1.8.2.jar
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar

These are some examples of the problems that arise.
Using that magic regex that you mentioned (which we use in archiva 
too!) we get a 1 to many split from path to reference.


(using "|" syntax for examples of references below 
groupId|artifactId|version|type)


ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
  becomes one of the following
ch.ethz.ganymed|ganymed|ssh2-build210|jar
ch.ethz.ganymed|ganymed-ssh2|build210|jar


exactly - that's why I suggested some special cases needed to be 
listed (dom4j is a common one too).


The special case work can be accomplished with the proposal.
I don't like it, it screams *hack*, but if it'll get us closer to 1.0 
then so be it.






maven/jars/maven-test-plugin-1.8.2.jar
  becomes one of the following
maven|maven|test-plugin-1.8.2|jar
maven|maven-test-plugin|1.8.2|jar


seems like a bug, that should be deterministic through the filename 
extension


How does the extension affect the breakdown of the version id?



The initial proposal was to eliminate this 1 to many problem by 
reading the pom file for the information regarding the groupId / 
artifactId / version, but that isn't a valid solution when working 
with content that needs to be proxied.


Right, and it's not practical in general - so what is the current 
status? The proposal is too complicated a solution - I would rather we 
get it to work for 90% of the artifacts, special case the rest, and be 
done with it. If we really, really find we need to have it 100% 
deterministic with special cases, then I'd prefer we go back to adding 
alternate views on the repository.


We don't have 90% coverage of m1/legacy repos.
When I run through a simple LegacyLayout.toArtifact(path) on the files 
(paths only) present in the 
http://people.apache.org/repo/m1-ibiblio-rsync-repository/ repository, i 
get a ~40% failure rate.


I think I'll add that file listing to the unit tests today and make that 
a unit test.

Must pass with <10% failure rate.

The reworking of the layout routines has allowed for greater flexibility 
along with proper usage by the consumers.




But in either case, I think this can be in post-1.0. It's getting way 
too late for changes of the magnitude you are proposing.


The magnitude isn't as large as you think, it's mostly done already.
Just wrapping up the unit testing today.

- Joakim

Re: [Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

I think you are missing the core point of the proposal.

(Is nicolas the only one that understands the difficulty?)

Using *just* the path information, how do you get from a maven 1 request 
to an artifact reference?

(groupId, artifactId, version, type)

ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
maven/jars/maven-test-plugin-1.8.2.jar
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar

These are some examples of the problems that arise.
Using that magic regex that you mentioned (which we use in archiva too!) 
we get a 1 to many split from path to reference.


(using "|" syntax for examples of references below 
groupId|artifactId|version|type)


ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
  becomes one of the following
ch.ethz.ganymed|ganymed|ssh2-build210|jar
ch.ethz.ganymed|ganymed-ssh2|build210|jar

maven/jars/maven-test-plugin-1.8.2.jar
  becomes one of the following
maven|maven|test-plugin-1.8.2|jar
maven|maven-test-plugin|1.8.2|jar

org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar
  becomes one of the following
org.apache.geronimo.specs|geronimo|ejb_2.1_spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb|2.1_spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb_2.1|spec-1.0.1|jar
org.apache.geronimo.specs|geronimo-ejb_2.1_spec|1.0.1|jar

The process to get from maven 1 legacy request to a reference is not 
possible 100% of the time.
Any for the record, there is no code in maven 1 or maven 2 that does 
this (take a path and get an artifact reference), I've looked dozens of 
times, it just doesn't exist.


The initial proposal was to eliminate this 1 to many problem by reading 
the pom file for the information regarding the groupId / artifactId / 
version, but that isn't a valid solution when working with content that 
needs to be proxied.


- Joakim

Brett Porter wrote:

It took me a while to digest, but I think this is being over-thought.

I have some questions I need answering before I fully understand:
- "Discovering versions in a legacy layout. (do we need metadata 
update / snapshot purge here?)" -- not sure if it's what you meant, 
but no I don't think we need these so does that mean the problem isn't 
relevant?

- What are the reporting problems you refer to?
- why is classifier not applicable in legacy?

For the proposal, it looks ok (with the adjustments Nicolas made), but 
it also looks like what the code already does?


Some more things, just in point form...

Since it's problematic, why enumerate the artifact types? In m1, we 
can determine this purely on the filename extension so it's easy to 
detect.


" It is nearly impossible to detect, using the path alone, the correct 
artifactId or version" -- to address this in the regexes for the 
central repository we have a regex and some special cases. I think 
that might be suitable in this case (even if they have to be hand 
configured). The ones we have already determined should take care of 
central. I don't think you can rely on reading the POM - it may not 
exist, especially if you are mapping to another m1 repository, as you 
said. I wold be against doing this - it's probably what is causing 
most of the over-complication I see here.


I think the last part is key, as if we aren't re-reading the POM, I 
believe the code changes you discussed, and the 2 use cases in your 
second mail are irrelevant, is that right?


Just to wrap it up, you are correct about the first use case in your 
second mail - maven-metadata.xml requests are not in the legacy layout.


Cheers,
Brett


On 05/10/2007, at 11:58 PM, Joakim Erdfelt wrote:



This is a long email, read it all before commenting, and you'll likely
see a response to your earlier questions. :-)

I'm currently working on MRM-432 and MRM-519, and I'm in the middle 
of an

important change to how Archiva handles Layout detection, interaction,
and parsing.

:Background:

Layouts in Archiva have 2 main purposes.

 1. to convert a path to an artifact reference.
 2. to convert an artifact reference to a path.

Layouts are used by the following.

 1. The "/repository/${repoid}/" urls use layouts to determine the
Artifact Reference that the client is requesting.
The "/repository/" url is layout neutral, and can have maven 1
clients ask for content in legacy format, or maven 2 clients ask
for content in default layout.
 2. Proxy requests out to remote repositories utilize layouts to take
an internal Artifact Reference, convert it to a path appropriate
to the remote layout configuration and obtain the content that is
desired.
 3. Simple Consumers utilize layouts to obtain File references, and
Artifact References to the repository content for purposes of
operating on the content in a way that they desire.
 4. Complex consumers (such as metadata updater, and snapshots purge)
utilize layouts to obtain lists of v

Re: [Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

Hmm, You are correct.

Shortest path I can think of is junit/junit/3.8.1/junit-3.8.1.jar
That would be 4 parts, no?


 4. If 3 parts ( dir/dir/filename ) then
4.1. If part 2 name ends in "s" then test for potential legacy layout.
 4.1.1. Identify filename extension.
 4.1.2. Get potential list of artifact types for extension.
 4.1.3. If part 2 (minus the end "s")  is in the list of
artifact types == legacy layout
4.2. Can't be legacy, then hand off to default layout.


Lets change 4.2 to read ...
4.2.  Invalid legacy layout.

- Joakim

nicolas de loof wrote:

Just on question about the proposed logic for detecting layout.

4 If 3 parts ( dir/dir/filename ) then
...

Is there any case where a 3 part path can be a maven2 path ???

Nico.

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

This is a long email, read it all before commenting, and you'll likely
see a response to your earlier questions. :-)

I'm currently working on MRM-432 and MRM-519, and I'm in the middle of an
important change to how Archiva handles Layout detection, interaction,
and parsing.

:Background:

Layouts in Archiva have 2 main purposes.

1. to convert a path to an artifact reference.
2. to convert an artifact reference to a path.

Layouts are used by the following.

1. The "/repository/${repoid}/" urls use layouts to determine the
Artifact Reference that the client is requesting.
The "/repository/" url is layout neutral, and can have maven 1
clients ask for content in legacy format, or maven 2 clients ask
for content in default layout.
2. Proxy requests out to remote repositories utilize layouts to take
an internal Artifact Reference, convert it to a path appropriate
to the remote layout configuration and obtain the content that is
desired.
3. Simple Consumers utilize layouts to obtain File references, and
Artifact References to the repository content for purposes of
operating on the content in a way that they desire.
4. Complex consumers (such as metadata updater, and snapshots purge)
utilize layouts to obtain lists of versions and artifacts.

What Works.

* Converting an Artifact Reference to a path.
* Discovering Versions in a default layout.
   (needed by metadata update / snapshot purge)
* Converting a default layout path to an Artifact Reference correctly.

What Doesn't Work.

* Detecting the layout in use 100% of the time.
* Converting a legacy layout path to an Artifact Reference 100% of
   the time.
* Discovering versions in a legacy layout.
   (do we need metadata update / snapshot purge here?)
* Reporting problems correctly.

:The Problem:

The inability to parse useful information in a consistent way for all
provided paths.
Gleaning the following information from the path.

* Layout Type (default / legacy)
* Group ID
* Artifact ID
* Version (Deployed version & Base version)
* Classifier (Not applicable in legacy layout)
* Type (Not the same as Extension)

Example Paths: (included in this email for discussion, actual list
   from test cases)

groupId/jars/-1.0.jar
org.apache.maven.test/jars/artifactId-1.0.war
ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
javax/jars/comm-3.0-u1.jar
javax.persistence/jars/ejb-3.0-public_review.jar
maven/jars/maven-test-plugin-1.8.2.jar
commons-lang/jars/commons-lang-2.1.jar
org.apache.derby/jars/derby-10.2.2.0.jar
com.foo/ejbs/foo-client-1.0.jar
com.foo.lib/javadoc.jars/foo-lib-2.1-alpha-1-javadoc.jar
com.foo.lib/java-sources/foo-lib-2.1-alpha-1-sources.jar
com.foo/jars/foo-tool-1.0.jar
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar
directory-clients/poms/ldap-clients-0.9.1-SNAPSHOT.pom
org.apache.archiva.test/jars/redonkulous-3.1-beta-1-20050831.101112-42.jar
invalid/invalid/1.0-20050611.123456-1/invalid-1.0-20050611.123456-1.jar
ch/ethz/ganymed/ganymed-ssh2/build210/ganymed-ssh2-build210.jar
javax/comm/3.0-u1/comm-3.0-u1.jar
javax/persistence/ejb/3.0-public_review/ejb-3.0-public_review.jar
maven/maven-test-plugin/1.8.2/maven-test-plugin-1.8.2.pom
test/maven-arch/test-arch/2.0.3-SNAPSHOT/test-arch-2.0.3-SNAPSHOT.pom
com/company/department/com.company.department/0.2/com.company.department-
0.2.pom

com/company/department/com.company.department.project/0.3/com.company.department.project-
0.3.pom
com/foo/foo-tool/1.0/foo-tool-1.0.jar
commons-lang/commons-lang/2.1/commons-lang-2.1.jar
com/foo/foo-client/1.0/foo-client-1.0.jar
com/foo/lib/foo-lib/2.1-alpha-1/foo-lib-2.1-alpha-1-sources.jar
org/apache/archiva/test/redonkulous/3.1-beta-1-SNAPSHOT/redonkulous-
3.1-beta-1-20050831.101112-42.jar

:Proposal:

The proposed logic for detecting layout.

1. Split path by directory seperators.
2. If more than 3 parts ( dir/dir/dir/dir/filename ) == default layout.
3. If less than 3 parts ( dir/filename ) == invalid path.
4. If 3 parts ( dir/dir/filename ) then
4.1. If part 2 name ends in "s&quo

Re: [Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

A few more use cases to worry about.

Use Case 1:
Request on "/repository/" url for maven-metadata.xml.

Problem: Assume Default Layout for all maven-metadata.xml requests?

Use Case 2:
Request on "/repository/" url using maven 1 legacy style for content 
that doesn't exist and needs to arrive via proxy connector from remote 
repository?


Problem: Can't parse pom (we don't have it yet) to get ArtifactReference 
in order to make request to remote repository


Use Case 3:
Request on "/repository/" url using maven 1 legacy style, but for 
content that is stored in default layout.


Problem: Catch-22: Need to parse path to Artifact Reference in order to 
load pom, in order to know the Artifact Reference to the pom to load.


- Joakim

If a request arrives into the "/repository/" url tha

Joakim Erdfelt wrote:


This is a long email, read it all before commenting, and you'll likely
see a response to your earlier questions. :-)

I'm currently working on MRM-432 and MRM-519, and I'm in the middle of an
important change to how Archiva handles Layout detection, interaction,
and parsing.

:Background:

Layouts in Archiva have 2 main purposes.

 1. to convert a path to an artifact reference.
 2. to convert an artifact reference to a path.

Layouts are used by the following.

 1. The "/repository/${repoid}/" urls use layouts to determine the
Artifact Reference that the client is requesting.
The "/repository/" url is layout neutral, and can have maven 1
clients ask for content in legacy format, or maven 2 clients ask
for content in default layout.
 2. Proxy requests out to remote repositories utilize layouts to take
an internal Artifact Reference, convert it to a path appropriate
to the remote layout configuration and obtain the content that is
desired.
 3. Simple Consumers utilize layouts to obtain File references, and
Artifact References to the repository content for purposes of
operating on the content in a way that they desire.
 4. Complex consumers (such as metadata updater, and snapshots purge)
utilize layouts to obtain lists of versions and artifacts.

What Works.

 * Converting an Artifact Reference to a path.
 * Discovering Versions in a default layout.
   (needed by metadata update / snapshot purge)
 * Converting a default layout path to an Artifact Reference correctly.

What Doesn't Work.

 * Detecting the layout in use 100% of the time.
 * Converting a legacy layout path to an Artifact Reference 100% of
   the time.
 * Discovering versions in a legacy layout.
   (do we need metadata update / snapshot purge here?)
 * Reporting problems correctly.

:The Problem:

The inability to parse useful information in a consistent way for all
provided paths.
Gleaning the following information from the path.

 * Layout Type (default / legacy)
 * Group ID
 * Artifact ID
 * Version (Deployed version & Base version)
 * Classifier (Not applicable in legacy layout)
 * Type (Not the same as Extension)

Example Paths: (included in this email for discussion, actual list
   from test cases)

groupId/jars/-1.0.jar
org.apache.maven.test/jars/artifactId-1.0.war
ch.ethz.ganymed/jars/ganymed-ssh2-build210.jar
javax/jars/comm-3.0-u1.jar
javax.persistence/jars/ejb-3.0-public_review.jar
maven/jars/maven-test-plugin-1.8.2.jar
commons-lang/jars/commons-lang-2.1.jar
org.apache.derby/jars/derby-10.2.2.0.jar
com.foo/ejbs/foo-client-1.0.jar
com.foo.lib/javadoc.jars/foo-lib-2.1-alpha-1-javadoc.jar
com.foo.lib/java-sources/foo-lib-2.1-alpha-1-sources.jar
com.foo/jars/foo-tool-1.0.jar
org.apache.geronimo.specs/jars/geronimo-ejb_2.1_spec-1.0.1.jar
directory-clients/poms/ldap-clients-0.9.1-SNAPSHOT.pom
org.apache.archiva.test/jars/redonkulous-3.1-beta-1-20050831.101112-42.jar 


invalid/invalid/1.0-20050611.123456-1/invalid-1.0-20050611.123456-1.jar
ch/ethz/ganymed/ganymed-ssh2/build210/ganymed-ssh2-build210.jar
javax/comm/3.0-u1/comm-3.0-u1.jar
javax/persistence/ejb/3.0-public_review/ejb-3.0-public_review.jar
maven/maven-test-plugin/1.8.2/maven-test-plugin-1.8.2.pom
test/maven-arch/test-arch/2.0.3-SNAPSHOT/test-arch-2.0.3-SNAPSHOT.pom
com/company/department/com.company.department/0.2/com.company.department-0.2.pom 

com/company/department/com.company.department.project/0.3/com.company.department.project-0.3.pom 


com/foo/foo-tool/1.0/foo-tool-1.0.jar
commons-lang/commons-lang/2.1/commons-lang-2.1.jar
com/foo/foo-client/1.0/foo-client-1.0.jar
com/foo/lib/foo-lib/2.1-alpha-1/foo-lib-2.1-alpha-1-sources.jar
org/apache/archiva/test/redonkulous/3.1-beta-1-SNAPSHOT/redonkulous-3.1-beta-1-20050831.101112-42.jar 



:Proposal:

The proposed logic for detecting layout.

 1. Split path by directory seperators.
 2. If more than 3 parts ( dir/dir/dir/dir/filename ) == default layout.
 3. If less than 3 parts ( dir/filename ) == invalid path.
 4. If 3 parts ( dir/dir/filename ) then
4.1. If part 2 na

[Proposal] Repository Layout Detection/Interaction Changes.

[Joakim Erdfelt]

me, we get the
 following order.

 dirs[dirs.length] = base version.
 dirs[dirs.length-1] = artifact Id.
 dirs[0] thru dirs[dirs.length-2] = groupId.

 That gives us the crucial pieces in the filename
 ${artifactId}-${version}, which makes detecting the classifier and
 type easy enough.

The proposed logic for parsing legacy layout paths.

 Legacy layouts are tricky.  It is nearly impossible to detect, using
 the path alone, the correct artifactId or version.  So the process
 will need to read the pom file associated with the artifact Id in order
 to determine the correct Artifact Reference pieces.

 The problem with this approach is that we now need 2 pieces of
 information, the repository root (location or url) and the path.
 Plus we incur a hit / read of the pom file.

 So, if we use the pseudo-pattern ...
 [:groupId:]/[:type:]s/[:filename:].[:ext:]
 as a starting point, swap out the [:type:] and [:ext:] for "pom" and
 load the pom from the actual repository to determine the groupId,
 artifactId, and version, we can then have an valid Artifact Reference.

 The problem with relying on the pom is that it is now required for
 legacy layout "from path" logic, this changes the assumption that poms
 are optional and not required, as well as changing the interface
 to the layout objects to needing a repository as well.

The proposed changes to the codebase.

 * Eliminate RepositoryLayoutUtils, roll layout specific filename
   parsing routines into their respected layouts.
 * Eliminate direct usage of BidirectionalRepositoryLayout by
   consumers.
 * Create RepositoryContentRequest that takes the freeform requests
   arriving in from the "/repository/" urls and puts it through
   the logic as outlined above.
 * Rename BidirectionalRepositoryLayout interface to RepositoryContent
   to simplify name and represent new role of accessing repository
   content that requires a repository reference.
 * Create DefaultRepositoryContent and LegacyRepositoryContent
   implementations, that utilize techniques described above, and
   logic already present in DefaultBidirectionalRepositoryLayout and
   LegacayBidirectionalRepositoryLayout.
 * Create AnonymousProjectReader that takes a File object pointing to
   a pom, read the  or  elements and load
   the pom information as appropriate.
 * Create RepositoryContentFactory that returns a RepositoryContent
   implementation for the provided repository id.

Example of new RepositoryContent interface.

--(snip)--
package org.apache.maven.archiva.repository;

/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements.  See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership.  The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License.  You may obtain a copy of the License at
*
*  http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied.  See the License for the
* specific language governing permissions and limitations
* under the License.
*/

import org.apache.maven.archiva.model.ArtifactReference;
import org.apache.maven.archiva.model.ProjectReference;
import org.apache.maven.archiva.model.VersionedReference;
import org.apache.maven.archiva.repository.layout.LayoutException;

import java.util.List;

/**
* RepositoryContent interface for interacting with a managed repository
* in an abstract way, without the need for processing based on
* filesystem paths, or working with the database.
*
* @author mailto:[EMAIL PROTECTED]">Joakim Erdfelt
* @version $Id$
*/
public interface RepositoryContent
{
   /**
* Determines if the project referenced exists in the repository.
*
* @param reference the project reference to check for.
* @return true it the project referenced exists.
*/
   public boolean hasContent( ProjectReference reference );

   /**
* Determines if the version reference exists in the repository.
*
* @param reference the version reference to check for.
* @return true if the version referenced exists.
*/
   public boolean hasContent( VersionedReference reference );

   /**
* Determines if the artifact referenced exists in the repository.
*
* @param reference the artifact reference to check for.
* @return true if the artifact referenced exists.
*/
   public boolean hasContent( ArtifactReference reference );

   /**
* Given a repository relative path to a filename, return the
* [EMAIL PROTECTED] VersionedReference} object suitable for the path.
*
* @param path the path relative to the repository base dir for
*the artifact.
* @return the [E

Problems with Legacy Layout Detection (Was: Re: critical issue with 1.0-beta-2 !!!)

[Joakim Erdfelt]

  

I just don't understand : if the requested artifact & pom is stored in
a m2-layout repository, we cannot just replace the extention with
"pom" to get it, we still need to build a valid m2 path.

The pom is allready requested by the server-side relocation, but this
can only occurs after the artifactId has been resolved.

Nico.




  



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

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

[Joakim Erdfelt]

In regards to the second idea.

It's two fold.

First part is to split the /repository/ into 
/repository/${repoid}/${layout}/${resource}

This is to eliminate the guessing, the ambiguity, etc.

Second part is to dive deeper when working with legacy paths to request 
the pom for the same resource path and utilize the information present 
in that pom to better determine the correct artifactId / version that 
the original author intended.


This can be accomplished by simply replacing the extension with .pom and 
fetching that content too.


- Joakim

nicolas de loof wrote:

The idea of having a set of potential artifactIds is an interesting alternative.

This might produce more network traffic on proxies, but is the only
way to ensure the expected artifact requested by maven1 is found in a
maven2 repo. Maybe a cache could be set to maintain Last recently
Resolved legacy requests ? Or maybe some more meta-data can be sored
in DB and attached to the groupId ?

Having the repository URL splitted into deterministic layouts will not
solve the Maven1-request-to-maven2-managed-repository issue. What do
you mean about "Use this along with pom information on the same file
should clear up any confusion" as to read the expected pom we need the
artifactId, don't we ?

About MRM-517, it looks strange that those path are resolved to legacy
layout as they include more than 3 "/". The legacy layout only applies
when the path contains 2 "/" (group/types/artifact.type). I don't have
the source code here to confirm this and look further, and will
inversitgate this one tomorrow.


Nico.

2007/9/26, Joakim Erdfelt <[EMAIL PROTECTED]>:
  

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

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

[Joakim Erdfelt]

Geez. my very first sentence has an error. :-(

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

There, now I feel better.

- Joakim

Joakim Erdfelt wrote:

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: [proposal] Move Archiva's wiki to cwiki.apache.org

[Joakim Erdfelt]

OK, I answered one of my questions just fine.

http://cwiki.apache.org/ACTIVEMQ/ == http://activemq.apache.org/

That's what I'd like to accomplish for Archiva too.

- Joakim

Joakim Erdfelt wrote:

A few questions, possible tweaks to this.

1) Why the split between ARCHIVADEV and ARCHIVA?
2) Is there any kind of Apache legal hiccups with the free submittal 
of documentation without a CLA type document?
3) Can this cwiki be the homepage of archiva itself?  Does it need to 
be on cwiki.apache.org?  Can't it be on 
http://maven.apache.org/archiva/ ?


I would love to see us move away from the stodgy xdoc / apt way of 
managing doc, to using a wiki *ANY WIKI* to be _the_ documentation for 
Archiva.  But I'm worried about the legal angle of it.  We probably 
couldn't bundle an export of the documentation into a PDF format (for 
example) if it contains anonymous updates.


*shrug*

- Joakim

Brett Porter wrote:

Hi,

Archiva currently has a subsection of the Maven user's wiki, which is 
a bit out of place.


I'd like to propose we create two spaces on cwiki.apache.org:
- ARCHIVADEV - for roadmap/proposals/etc. (edited by developers)
- ARCHIVA - for knowledge-base/faq type content (edited by users)

I will probably import the whole space into ARCHIVA, delete anything 
not related to Archiva, then move the development pages out. That 
will make it retain history, and should still be faster than copying 
individual pages.


Both can use the template I already made to automatically be 
generated to static HTML and be inserted into a subsection of the 
Archiva site.


Thoughts?

- Brett







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

Re: [proposal] Move Archiva's wiki to cwiki.apache.org

[Joakim Erdfelt]

A few questions, possible tweaks to this.

1) Why the split between ARCHIVADEV and ARCHIVA?
2) Is there any kind of Apache legal hiccups with the free submittal of 
documentation without a CLA type document?
3) Can this cwiki be the homepage of archiva itself?  Does it need to be 
on cwiki.apache.org?  Can't it be on http://maven.apache.org/archiva/ ?


I would love to see us move away from the stodgy xdoc / apt way of 
managing doc, to using a wiki *ANY WIKI* to be _the_ documentation for 
Archiva.  But I'm worried about the legal angle of it.  We probably 
couldn't bundle an export of the documentation into a PDF format (for 
example) if it contains anonymous updates.


*shrug*

- Joakim

Brett Porter wrote:

Hi,

Archiva currently has a subsection of the Maven user's wiki, which is 
a bit out of place.


I'd like to propose we create two spaces on cwiki.apache.org:
- ARCHIVADEV - for roadmap/proposals/etc. (edited by developers)
- ARCHIVA - for knowledge-base/faq type content (edited by users)

I will probably import the whole space into ARCHIVA, delete anything 
not related to Archiva, then move the development pages out. That will 
make it retain history, and should still be faster than copying 
individual pages.


Both can use the template I already made to automatically be generated 
to static HTML and be inserted into a subsection of the Archiva site.


Thoughts?

- Brett




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

Re: Bug bash!

[Joakim Erdfelt]

Count me in.
Tho I feel like I've already started. ;-)

- Joakim

Brett Porter wrote:
Anybody else? with beta-2 out now we have a really good baseline to 
work against.


- Brett

On 17/09/2007, at 12:52 PM, Maria Odea Ching wrote:


Brett Porter wrote:

Hi,

Running the beta this morning I was able to find a bunch of nuisance 
bugs. Looking through JIRA there are quite a few things that could 
probably be delayed beyond 1.0, but there are a lot of things not 
listed that would be important to get done.


I'm thinking of spending a few hours running through every feature 
thoroughly and filing bugs for things I find - this would at least 
find obvious things in the UI. The more volunteers to do this we 
have, the better - we can partition the app among us, and double 
check some parts. Who would be able to do this over the next couple 
of days?


I can devote a few hours this week too for the bug bash..



With that list in hand I think we could revise and cut down what 
needs to be done for 1.0 once beta-2 is out, because aside from 
documentation it looks pretty much baked to me.


Cheers,
Brett

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





Thanks,
Deng



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




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

MRM-333: Tomcat Issues and Tested Versions.

[Joakim Erdfelt]

I'm in the middle of working out the MRM-333 issues, and want some input
on what versions of Tomcat I should focus on?

So far, I have ...

Tomcat 5.0.28 (binary + deployer)
Tomcat 5.5.25 (binary + deployer + admin webapp)
Tomcat 6.0.14 (binary + deployer)

Should I narrow this down any?
Should I focus on binary install technique only?
Should I document how to use the deployer with archiva?
Should I document how to use the admin webapp with archiva?

Input / Suggestions?

- Joakim