Re: Virtual Repositories

[nicolas de loof]

2.1.bis - on metadata request, merge all repositories metadatas

2.1.ter - on index request (nexus index requested by many m2eclipse users),
merge all repositories indexes

Nico.


2008/4/17, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> Hi everyone,
>
> A group of us here from Exist bounced around some thoughts on how to
> approach implementing the virtual repositories concept in Archiva (
> http://jira.codehaus.org/browse/MRM-694). So far, we've came up with a
> list
> of things that might need to be changed in order to implement this
> feature:
>
> 1. Configuration -- add the repository group in managed repositories
> configuration. It is assumed here that a repository can belong to multiple
> repository groups.
>1.1 UI
> - update the repositories page (add a field that contains the list of
> repo groups -- the list can be links to the browse by repository groups)
> - browse repository groups page
> - repo group connectors page (similar to proxy connector)
>
>1.2 archiva.xml
> - add a RepositoryGroup class in configuration model
> - set a default configuration for the repo group (might not be
> necessary)
>
> 2. Webdav module
>2.1 handle requests with repository group urls
> - iterate through the repositories under the group and return the
> first
> artifact found. If not found, return a 404.
>
>2.2 attempt to deploy in the group should return a "BAD REQUEST"
>
> 3. Security/permission
>3.1 ignore the repositories which the user does not have permission to
> access (this would tie up with 2.1)
>
> Wdyt?
> Suggestions, comments, violent reactions are all welcome :-)
>
>
> Thanks,
> Deng
>

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

[nicolas de loof]

+1

2008/4/16, Fabrice Bellingard <[EMAIL PROTECTED]>:
>
> Yes, let's vote now! :-)
>
> +1 for James
>
> Cheers
>
>
> --
> Fabrice
> - [EMAIL PROTECTED] -
>
>
> On Wed, Apr 16, 2008 at 5:20 AM, Brett Porter <[EMAIL PROTECTED]> 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: [vote] Release Archiva 1.0.2

[nicolas de loof]

+1

2008/4/4, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> Re-opened MRM-605.
>
> Anyway, the binaries are working nicely all in all :-)
> Thanks for preparing the release Brett!
>
> -Deng
>
> On Fri, Apr 4, 2008 at 12:20 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> > can you (re)open the issue for that? I'll try it again but I thought it
> > was taken care of.
> >
> > - Brett
> >
> > On 04/04/2008, at 3:04 PM, Maria Odea Ching wrote:
> >
> >  +1! :-)
> > >
> > > I've checked the signatures and checksums, and they're all correct.
> > > Proxying
> > > works nicely and the log files are organized too.
> > >
> > > I'm getting the test failure in the sources distribution again
> > > (archiva-repository-layer) though but this is not a blocker for the
> > > release.
> > >
> > > Thanks,
> > > Deng
> > >
> > >
> > > On Fri, Apr 4, 2008 at 1:23 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > >
> > >  Hi
> > > >
> > > > The Archiva 1.0.2 release candidate has been staged.
> > > >
> > > > This release includes 41 fixes. You can take a look at the release
> > > > notes
> > > > here:
> > > >
> > > >
> > > >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=14052
> > > > or
> > > >
> > > >
> > > >
> http://people.apache.org/~brett/staged-sites/archiva/1.0.2/release-notes.html
> <
> http://people.apache.org/%7Ebrett/staged-sites/archiva/1.0.2/release-notes.html
> >
> > > > <
> > > >
> http://people.apache.org/%7Ebrett/staged-sites/archiva/1.0.2/release-notes.html
> > > > >
> > > >
> > > > The whole staged site is here:
> > > >  http://people.apache.org/~brett/staged-sites/archiva/1.0.2/<
> http://people.apache.org/%7Ebrett/staged-sites/archiva/1.0.2/>
> > > > 
> > > >
> > > > While the binaries, including the sources, signatures and checksums,
> > > > can
> > > > be downloaded here:
> > > >  http://people.apache.org/builds/maven/archiva/1.0.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.
> > > >
> > > > Thanks,
> > > > Brett
> > > >
> > > > --
> > > > Brett Porter
> > > > [EMAIL PROTECTED]
> > > > http://blogs.exist.com/bporter/
> > > >
> > > >
> > > >
> > --
> > Brett Porter
> > [EMAIL PROTECTED]
> > http://blogs.exist.com/bporter/
> >
> >
>

Re: merge spring branch to trunk?

[nicolas de loof]

Nothing left for me. My +1 to merge

Not beeing at home this week I cannot acces SVN.

Nico

2008/3/12, Brett Porter <[EMAIL PROTECTED]>:
>
> Hi Nicolas,
>
> What is left before merging the branch in?
>
> - Brett
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

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

[nicolas de loof]

http://jira.codehaus.org/browse/PLX-366


2008/3/7, Olivier Lamy <[EMAIL PROTECTED]>:
>
> 2008/3/4, Rahul Thakur <[EMAIL PROTECTED]>:
> >
> >  Is 'plexus-spring' moving to Plexus SVN then?
>
> IMHO, this will be great.
>
> Is there any legacy issue to moving this ?
>
> If not, nicolas, as you are not a plexus committer.
> Can you load an issue in jira with an attached patch ?
> We can put this in
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-components/
>
> Thanks,
> --
> Olivier
>
> >
> >  +1 for merge if all is good to go.
> >
> >  Cheers,
> >
> > Rahul
> >
> >
> >
> >  Brett Porter wrote:
> >  > 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: svn commit: r633841 - /maven/archiva/branches/springy/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/legacy/AddLegacyArtifactPathAction.java

[nicolas de loof]

Ooops, forgot I switched my SVN working copy to the springy branch...

As we are now ready to merge with trunk, does this really matter ?
Nico.

2008/3/5, Brett Porter <[EMAIL PROTECTED]>:
>
> shouldn't this be on trunk and 1.0.x branch, not on the spring branch?
>
> On 06/03/2008, at 12:24 AM, [EMAIL PROTECTED] wrote:
>
> > Author: nicolas
> > Date: Wed Mar  5 05:24:50 2008
> > New Revision: 633841
> >
> > URL: http://svn.apache.org/viewvc?rev=633841&view=rev
> > Log:
> > fix inversion between calssifier & version
> >
> > Modified:
> >maven/archiva/branches/springy/archiva-web/archiva-webapp/src/
> > main/java/org/apache/maven/archiva/web/action/admin/legacy/
> > AddLegacyArtifactPathAction.java
> >
> > Modified: maven/archiva/branches/springy/archiva-web/archiva-webapp/
> > src/main/java/org/apache/maven/archiva/web/action/admin/legacy/
> > AddLegacyArtifactPathAction.java
> > URL:
> http://svn.apache.org/viewvc/maven/archiva/branches/springy/archiva-web/archiva-webapp/src/main/java/org/apache/maven/archiva/web/action/admin/legacy/AddLegacyArtifactPathAction.java?rev=633841&r1=633840&r2=633841&view=diff
> > =
> > =
> > =
> > =
> > =
> > =
> > =
> > =
> > ==
> > --- maven/archiva/branches/springy/archiva-web/archiva-webapp/src/
> > main/java/org/apache/maven/archiva/web/action/admin/legacy/
> > AddLegacyArtifactPathAction.java (original)
> > +++ maven/archiva/branches/springy/archiva-web/archiva-webapp/src/
> > main/java/org/apache/maven/archiva/web/action/admin/legacy/
> > AddLegacyArtifactPathAction.java Wed Mar  5 05:24:50 2008
> > @@ -78,7 +78,7 @@
> > public String commit()
> > {
> > this.legacyArtifactPath.setArtifact(
> > -this.groupId + ":" + this.artifactId + ":" +
> > this.classifier + ":" +  this.version + ":" + this.type );
> > +this.groupId + ":" + this.artifactId + ":" +
> > this.version + ":" +  this.classifier + ":" + this.type );
> >
> > // Check the proposed Artifact macthes the path
> > ArtifactReference artifact = new ArtifactReference();
> >
> >
>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

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

[nicolas de loof]

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: svn commit: r631999 - in /maven/archiva/branches/springy: archiva-base/archiva-common/ archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/ archiva-base/archiva

[nicolas de loof]

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

Re: svn commit: r632495 - in /maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring: PlexusComponentFactoryBean.java PlexusNamespaceHandler.java

[nicolas de loof]

thanks, Brett allready reported this but I definitly have troubles with the
world "instantiation" ;-)

2008/3/1, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Author: rinku
> Date: Fri Feb 29 15:26:27 2008
> New Revision: 632495
>
> URL: http://svn.apache.org/viewvc?rev=632495&view=rev
> Log:
> o  fixed minor typo.
> o  organised imports in PlexusComponentFactoryBean and
> PlexusNamespaceHandler.
>
> Modified:
>
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusComponentFactoryBean.java
>
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusNamespaceHandler.java
>
> Modified:
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusComponentFactoryBean.java
> URL:
> http://svn.apache.org/viewvc/maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusComponentFactoryBean.java?rev=632495&r1=632494&r2=632495&view=diff
>
> ==
> ---
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusComponentFactoryBean.java
> (original)
> +++
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusComponentFactoryBean.java
> Fri Feb 29 15:26:27 2008
> @@ -22,33 +22,18 @@
> import java.lang.reflect.Field;
> import java.util.Collection;
> import java.util.Iterator;
> -import java.util.LinkedList;
> -import java.util.List;
> import java.util.Map;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> -import org.codehaus.plexus.PlexusContainer;
> -import org.codehaus.plexus.context.Context;
> -import org.codehaus.plexus.context.ContextException;
> -import org.codehaus.plexus.logging.LogEnabled;
> -import org.codehaus.plexus.logging.LoggerManager;
> -import
> org.codehaus.plexus.personality.plexus.lifecycle.phase.Contextualizable;
> -import org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable;
> -import
> org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable;
> -import
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializationException
> ;
> -import org.springframework.beans.BeansException;
> import org.springframework.beans.SimpleTypeConverter;
> import org.springframework.beans.TypeConverter;
> import org.springframework.beans.factory.BeanCreationException;
> import org.springframework.beans.factory.BeanFactory;
> import org.springframework.beans.factory.BeanFactoryAware;
> import org.springframework.beans.factory.BeanInitializationException;
> -import org.springframework.beans.factory.DisposableBean;
> import org.springframework.beans.factory.FactoryBean;
> -import org.springframework.beans.factory.InitializingBean;
> import org.springframework.beans.factory.ListableBeanFactory;
> -import org.springframework.beans.factory.config.AbstractFactoryBean;
> import org.springframework.beans.factory.config.ConfigurableBeanFactory;
> import org.springframework.beans.factory.config.RuntimeBeanReference;
> import org.springframework.util.ReflectionUtils;
> @@ -278,19 +263,19 @@
> }
>
> /**
> - * @param instanciationStrategy the instanciationStrategy to set
> + * @param instantiationStrategy the instantiationStrategy to set
>  */
> -public void setInstanciationStrategy( String instanciationStrategy )
> +public void setInstantiationStrategy( String instantiationStrategy )
> {
> -if ( instanciationStrategy.length() == 0 )
> +if ( instantiationStrategy.length() == 0 )
> {
> -instanciationStrategy = SINGLETON;
> +instantiationStrategy = SINGLETON;
> }
> -if ( "poolable".equals( instanciationStrategy ) )
> +if ( "poolable".equals( instantiationStrategy ) )
> {
> -throw new BeanCreationException( "Plexus poolable
> instanciation-strategy is not supported" );
> +throw new BeanCreationException( "Plexus poolable
> instantiation-strategy is not supported" );
> }
> -this.instantiationStrategy = instanciationStrategy;
> +this.instantiationStrategy = instantiationStrategy;
> }
>
> /**
>
> Modified:
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusNamespaceHandler.java
> URL:
> http://svn.apache.org/viewvc/maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusNamespaceHandler.java?rev=632495&r1=632494&r2=632495&view=diff
>
> ==
> ---
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusNamespaceHandler.java
> (original)
> +++
> maven/archiva/branches/springy/plexus-spring/src/main/java/org/codehaus/plexus/spring/PlexusNamespaceHandler.java
> Fri Feb 29 15:26:27 2008
> @@ -21,34 +21,20 @@
>
> import java.io.P

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

[nicolas de loof]

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

Re: from plexus to spring...

[nicolas de loof]

Yes, it has been removed as there is no more requirement for application
code to lookup for dependencies from either PlexusFactory or SpringFactory.
All the spring-support related code has move to plexus-spring project (at
branch root).

plexus-spring will inject components/beans created in a spring context in
both plexus-components / spring-beans according to spring applicationContext
xml files AND plexus componnents.xml descriptors.

Nico.


2008/2/29, Rahul Thakur <[EMAIL PROTECTED]>:
>
> Hi Nicolas,
>
> I just did an SVN update. It seems this is missing from sources:
> org.apache.maven.archiva.common.spring.PlexusFactory
>
> Cheers,
> Rahul
>
>
>
> nicolas de loof wrote:
> > That beeing said, with xwork xml files converted I can start archiva
> > and register my admin account RUNNING ON SPRING !
> >
> > Hey Rahul, seems you can start using plexus-spring on Continuum !
> >
> > Nicolas
> >
> >
> > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > Support for plexus  to Properties added in plexus-spring,
> >
> > Now have the following error when first access to /archiva webapp :
> >
> > Caused by: java.lang.ClassNotFoundException:
> > redbackEnvironmentCheckInterceptor
> > at
> > org.apache.catalina.loader.WebappClassLoader.loadClass(
> WebappClassLoader.java:1352)
> > at
> > org.apache.catalina.loader.WebappClassLoader.loadClass(
> WebappClassLoader.java:1198)
> > at
> > com.opensymphony.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java
> :104)
> > at
> > com.opensymphony.xwork.ObjectFactory.getClassInstance(
> ObjectFactory.java:88)
> > at
> > com.opensymphony.xwork.spring.SpringObjectFactory.getClassInstance(
> SpringObjectFactory.java:175)
> > at
> > com.opensymphony.xwork.spring.SpringObjectFactory.buildBean(
> SpringObjectFactory.java:116)
> >
> >
> > The expected component is declared in
> > redback-xwork-integration-1.0-alpha-4.jar :
> >
> >  
> >   com.opensymphony.xwork.interceptor.Interceptor
> >   redbackForceAdminUserInterceptor
> >   ...
> >
> > Using the convention used to convert plexus rold+hint to spring
> >     IDs, this result in a spring bean
> > id="interceptor#redbackForceAdminUserInterceptor".
> >
> > Editing xwork-security to use the expected IDs is not a valid
> > solution as this file comes from the war overlay.
> >
> > Any suggestion ?
> >
> > Nicolas.
> >
> >
> >
> > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > PlexusConfiguration support is now fixed.
> >
> > archiva-configuration tests pass with no change required,
> > except :
> >
> > PlexusTestCase --> PlexusInSpringTestCase
> > add getSpringConfigLocation() to return path to the new
> > spring-context.xml test resource
> >
> > [INFO]
> >
> 
> > [INFO] BUILD SUCCESSFUL
> > [INFO]
> >
> 
> >
> > I've also created a PlexusWebApplicationContext and tried to
> > start archiva webapp with spring... but this is not so easy :
> >
> >   change webwork.properties for : webwork.objectFactory = spring
> >   change web.xml to remove PlexusLifecycleListener
> >   use spring applicationContext to expose the
> >     PlexusContainerAdapter as "webwork.plexus.container"
> >
> > The web application starts and initialize many beans, but
> > fails during security framework setup :
> >
> > "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE
> > Set to 'JDK_DEFAULT_TIMEZONE' in order for jpox and
> > JdoKeyManager to operate correctly."
> >
> > The AbstractConfigurableJdoFactory requires conversion from
> > plexus  elements to Properties...
> >
> >
> > Nicolas.
> >
> >
> >
> >
> > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>>:
> >
> > I just committed partial support for

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

[nicolas de loof]

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

Re: from plexus to spring...

[nicolas de loof]

The problem is inverse :

The bean is registered in spring context as Interface#role-hint (for example
: id="action#searchAction" for a webwork action bean) and the Spring
ObjectFactory ask for a bean with only the role-hint.

A hack solution would be to use a custom SpringObejctFactory and search the
context for action# and interceptor#.

Nico.

2008/2/28, Brett Porter <[EMAIL PROTECTED]>:
>
> It's a bit of a hack, but if a bean lookup fails for
> Something#something, can you just remove the trailing #something and
> try again? I assume this is the problem?
>
>
> - Brett
>
>
> On 29/02/2008, at 3:46 AM, nicolas de loof wrote:
>
> > That beeing said, with xwork xml files converted I can start archiva
> > and register my admin account RUNNING ON SPRING !
> >
> > Hey Rahul, seems you can start using plexus-spring on Continuum !
> >
> > Nicolas
> >
> >
> > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]>:
> > Support for plexus  to Properties added in plexus-spring,
> >
> > Now have the following error when first access to /archiva webapp :
> >
> > Caused by: java.lang.ClassNotFoundException:
> > redbackEnvironmentCheckInterceptor
> > at
> > org
> > .apache
> > .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
> > 1352)
> > at
> > org
> > .apache
> > .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:
> > 1198)
> > at
> > com.opensymphony.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:
> > 104)
> > at
> > com
> > .opensymphony
> > .xwork.ObjectFactory.getClassInstance(ObjectFactory.java:88)
> > at
> > com
> > .opensymphony
> > .xwork
> > .spring
> > .SpringObjectFactory.getClassInstance(SpringObjectFactory.java:175)
> > at
> > com
> > .opensymphony
> > .xwork.spring.SpringObjectFactory.buildBean(SpringObjectFactory.java:
> > 116)
> >
> >
> > The expected component is declared in redback-xwork-integration-1.0-
> > alpha-4.jar :
> >
> >  
> >   com.opensymphony.xwork.interceptor.Interceptor
> >   redbackForceAdminUserInterceptor
> >   ...
> >
> > Using the convention used to convert plexus rold+hint to spring IDs,
> > this result in a spring bean
> > id="interceptor#redbackForceAdminUserInterceptor".
> >
> > Editing xwork-security to use the expected IDs is not a valid
> > solution as this file comes from the war overlay.
> >
> > Any suggestion ?
> >
> > Nicolas.
> >
> >
> >
> > 2008/2/28, nicolas de loof <[EMAIL PROTECTED]>:
> > PlexusConfiguration support is now fixed.
> >
> > archiva-configuration tests pass with no change required, except :
> >
> > PlexusTestCase --> PlexusInSpringTestCase
> > add getSpringConfigLocation() to return path to the new spring-
> > context.xml test resource
> >
> > [INFO]
> > 
> > [INFO] BUILD SUCCESSFUL
> > [INFO]
> > 
> >
> > I've also created a PlexusWebApplicationContext and tried to start
> > archiva webapp with spring... but this is not so easy :
> >
> >   change webwork.properties for : webwork.objectFactory = spring
> >   change web.xml to remove PlexusLifecycleListener
> >   use spring applicationContext to expose the PlexusContainerAdapter
> > as "webwork.plexus.container"
> >
> > The web application starts and initialize many beans, but fails
> > during security framework setup :
> >
> > "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set
> > to 'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to
> > operate correctly."
> >
> > The AbstractConfigurableJdoFactory requires conversion from plexus
> >  elements to Properties...
> >
> >
> > Nicolas.
> >
> >
> >
> >
> > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> > I just committed partial support for PlexusConfiguration :
> >
> > - as XML validation is disabled the XML configuration doesn't
> > require to be in a CDATA section
> > - the namespaceHandler detects structured configuration and creates
> > a DomPlexusConfiguration for it.
> > - Still have to implement DomPlexusConfiguration  as
> > XmlPlexusConfigurati

Re: from plexus to spring...

[nicolas de loof]

That beeing said, with xwork xml files converted I can start archiva and
register my admin account RUNNING ON SPRING !

Hey Rahul, seems you can start using plexus-spring on Continuum !

Nicolas


2008/2/28, nicolas de loof <[EMAIL PROTECTED]>:
>
> Support for plexus  to Properties added in plexus-spring,
>
> Now have the following error when first access to /archiva webapp :
>
> Caused by: java.lang.ClassNotFoundException:
> redbackEnvironmentCheckInterceptor
> at org.apache.catalina.loader.WebappClassLoader.loadClass(
> WebappClassLoader.java:1352)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(
> WebappClassLoader.java:1198)
> at com.opensymphony.util.ClassLoaderUtil.loadClass(
> ClassLoaderUtil.java:104)
> at com.opensymphony.xwork.ObjectFactory.getClassInstance(
> ObjectFactory.java:88)
> at com.opensymphony.xwork.spring.SpringObjectFactory.getClassInstance(
> SpringObjectFactory.java:175)
> at com.opensymphony.xwork.spring.SpringObjectFactory.buildBean(
> SpringObjectFactory.java:116)
>
>
> The expected component is declared in
> redback-xwork-integration-1.0-alpha-4.jar :
>
>  
>   com.opensymphony.xwork.interceptor.Interceptor
>   redbackForceAdminUserInterceptor
>   ...
>
> Using the convention used to convert plexus rold+hint to spring IDs, this
> result in a spring bean
> id="interceptor#redbackForceAdminUserInterceptor".
>
> Editing xwork-security to use the expected IDs is not a valid solution as
> this file comes from the war overlay.
>
> Any suggestion ?
>
> Nicolas.
>
>
>
> 2008/2/28, nicolas de loof <[EMAIL PROTECTED]>:
> >
> > PlexusConfiguration support is now fixed.
> >
> > archiva-configuration tests pass with no change required, except :
> >
> > PlexusTestCase --> PlexusInSpringTestCase
> > add getSpringConfigLocation() to return path to the new
> > spring-context.xml test resource
> >
> > [INFO]
> > 
> > [INFO] BUILD SUCCESSFUL
> > [INFO]
> > 
> >
> > I've also created a PlexusWebApplicationContext and tried to start
> > archiva webapp with spring... but this is not so easy :
> >
> >   change webwork.properties for : webwork.objectFactory = spring
> >   change web.xml to remove PlexusLifecycleListener
> >   use spring applicationContext to expose the PlexusContainerAdapter as
> > "webwork.plexus.container"
> >
> > The web application starts and initialize many beans, but fails during
> > security framework setup :
> >
> > "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set to
> > 'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to operate
> > correctly."
> >
> > The AbstractConfigurableJdoFactory requires conversion from plexus
> >  elements to Properties...
> >
> >
> > Nicolas.
> >
> >
> >
> > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> > >
> > > I just committed partial support for PlexusConfiguration :
> > >
> > > - as XML validation is disabled the XML configuration doesn't require
> > > to be in a CDATA section
> > > - the namespaceHandler detects structured configuration and creates a
> > > DomPlexusConfiguration for it.
> > > - Still have to implement DomPlexusConfiguration  as
> > > XmlPlexusConfiguration requires Xpp3Dom.
> > >
> > > Still some work on this feature and I expect to pass
> > > archiva-configuration tests.
> > >
> > > Nico.
> > >
> > >
> > > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> > > >
> > > > I've solved the main issues, added some tiny doc and unit tests.
> > > >
> > > > Still early alpha code but now stable and ready for review if you
> > > > want to test it on Continuum.
> > > >
> > > > Some tests (like DefaultPathParserTest) migrate succesfully to
> > > > spring context execution using the PlexusInSpringTestCase without any
> > > > change.
> > > >
> > > > Many other archiva tests fails as the XSLT translation cannot
> > > > convert XML formated "configuration" to be injected in
> > > > CommonsConfigurationRegistry as a PlexusConfiguration :
> > > >
> > > > 
> > > >   org.codehaus.plexus.registry.Registry
> > > 

Re: from plexus to spring...

[nicolas de loof]

Support for plexus  to Properties added in plexus-spring,

Now have the following error when first access to /archiva webapp :

Caused by: java.lang.ClassNotFoundException:
redbackEnvironmentCheckInterceptor
at org.apache.catalina.loader.WebappClassLoader.loadClass(
WebappClassLoader.java:1352)
at org.apache.catalina.loader.WebappClassLoader.loadClass(
WebappClassLoader.java:1198)
at com.opensymphony.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java
:104)
at com.opensymphony.xwork.ObjectFactory.getClassInstance(
ObjectFactory.java:88)
at com.opensymphony.xwork.spring.SpringObjectFactory.getClassInstance(
SpringObjectFactory.java:175)
at com.opensymphony.xwork.spring.SpringObjectFactory.buildBean(
SpringObjectFactory.java:116)


The expected component is declared in
redback-xwork-integration-1.0-alpha-4.jar :

 
  com.opensymphony.xwork.interceptor.Interceptor
  redbackForceAdminUserInterceptor
  ...

Using the convention used to convert plexus rold+hint to spring IDs, this
result in a spring bean
id="interceptor#redbackForceAdminUserInterceptor".

Editing xwork-security to use the expected IDs is not a valid solution as
this file comes from the war overlay.

Any suggestion ?

Nicolas.



2008/2/28, nicolas de loof <[EMAIL PROTECTED]>:
>
> PlexusConfiguration support is now fixed.
>
> archiva-configuration tests pass with no change required, except :
>
> PlexusTestCase --> PlexusInSpringTestCase
> add getSpringConfigLocation() to return path to the new 
> spring-context.xmltest resource
>
> [INFO]
> 
> [INFO] BUILD SUCCESSFUL
> [INFO]
> 
>
> I've also created a PlexusWebApplicationContext and tried to start archiva
> webapp with spring... but this is not so easy :
>
>   change webwork.properties for : webwork.objectFactory = spring
>   change web.xml to remove PlexusLifecycleListener
>   use spring applicationContext to expose the PlexusContainerAdapter as "
> webwork.plexus.container"
>
> The web application starts and initialize many beans, but fails during
> security framework setup :
>
> "The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set to
> 'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to operate
> correctly."
>
> The AbstractConfigurableJdoFactory requires conversion from plexus
>  elements to Properties...
>
>
> Nicolas.
>
>
>
> 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> >
> > I just committed partial support for PlexusConfiguration :
> >
> > - as XML validation is disabled the XML configuration doesn't require to
> > be in a CDATA section
> > - the namespaceHandler detects structured configuration and creates a
> > DomPlexusConfiguration for it.
> > - Still have to implement DomPlexusConfiguration  as
> > XmlPlexusConfiguration requires Xpp3Dom.
> >
> > Still some work on this feature and I expect to pass
> > archiva-configuration tests.
> >
> > Nico.
> >
> >
> > 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> > >
> > > I've solved the main issues, added some tiny doc and unit tests.
> > >
> > > Still early alpha code but now stable and ready for review if you want
> > > to test it on Continuum.
> > >
> > > Some tests (like DefaultPathParserTest) migrate succesfully to spring
> > > context execution using the PlexusInSpringTestCase without any change.
> > >
> > > Many other archiva tests fails as the XSLT translation cannot convert
> > > XML formated "configuration" to be injected in 
> > > CommonsConfigurationRegistry
> > > as a PlexusConfiguration :
> > >
> > > 
> > >   org.codehaus.plexus.registry.Registry
> > >   configured  
> > > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry
> > > 
> > >   
> > > 
> > >   
> > >> >config-name="org.apache.maven.archiva" config-at="
> > > org.apache.maven.archiva"/>
> > > 
> > >   
> > > 
> > >
> > > The current stylesheet converts such  to a blank value.
> > >
> > > To support such configuration, we need
> > >
> > > 1.  a String2PlexusConfiguration PropertyEditor (maybe not  trivial,
> > > but should be possible)
> > > 2.  a XSL way to store the configuration child nodes as XML
> > > attri

Re: from plexus to spring...

[nicolas de loof]

PlexusConfiguration support is now fixed.

archiva-configuration tests pass with no change required, except :

PlexusTestCase --> PlexusInSpringTestCase
add getSpringConfigLocation() to return path to the new
spring-context.xmltest resource

[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]


I've also created a PlexusWebApplicationContext and tried to start archiva
webapp with spring... but this is not so easy :

  change webwork.properties for : webwork.objectFactory = spring
  change web.xml to remove PlexusLifecycleListener
  use spring applicationContext to expose the PlexusContainerAdapter as "
webwork.plexus.container"

The web application starts and initialize many beans, but fails during
security framework setup :

"The JdoFactory property 'org.jpox.rdbms.dateTimezone' MUST BE Set to
'JDK_DEFAULT_TIMEZONE' in order for jpox and JdoKeyManager to operate
correctly."

The AbstractConfigurableJdoFactory requires conversion from plexus
 elements to Properties...


Nicolas.



2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
>
> I just committed partial support for PlexusConfiguration :
>
> - as XML validation is disabled the XML configuration doesn't require to
> be in a CDATA section
> - the namespaceHandler detects structured configuration and creates a
> DomPlexusConfiguration for it.
> - Still have to implement DomPlexusConfiguration  as
> XmlPlexusConfiguration requires Xpp3Dom.
>
> Still some work on this feature and I expect to pass archiva-configuration
> tests.
>
> Nico.
>
>
> 2008/2/27, nicolas de loof <[EMAIL PROTECTED]>:
> >
> > I've solved the main issues, added some tiny doc and unit tests.
> >
> > Still early alpha code but now stable and ready for review if you want
> > to test it on Continuum.
> >
> > Some tests (like DefaultPathParserTest) migrate succesfully to spring
> > context execution using the PlexusInSpringTestCase without any change.
> >
> > Many other archiva tests fails as the XSLT translation cannot convert
> > XML formated "configuration" to be injected in CommonsConfigurationRegistry
> > as a PlexusConfiguration :
> >
> > 
> >   org.codehaus.plexus.registry.Registry
> >   configured  
> > org.codehaus.plexus.registry.commons.CommonsConfigurationRegistry
> > 
> >   
> > 
> >   
> >>config-name="org.apache.maven.archiva" config-at="
> > org.apache.maven.archiva"/>
> > 
> >   
> > 
> >
> > The current stylesheet converts such  to a blank value.
> >
> > To support such configuration, we need
> >
> > 1.  a String2PlexusConfiguration PropertyEditor (maybe not  trivial, but
> > should be possible)
> > 2.  a XSL way to store the configuration child nodes as XML attributes.
> >
> > I'm a XSL newbee so have no idea how to output the current node and all
> > it's children as a text content.
> > I've tested  but without the expected result.
> >
> > I also tried to set the configuration value as a nested CDATA content,
> > but cannot find how to create the plexus:configuration content as as CDATA
> > element.   didn't
> > fix this.
> >
> >
> >
> >
> >
> >
> >
> >
> > 2008/2/26, nicolas de loof <[EMAIL PROTECTED]>:
> > >
> > > For your information, plexus-spring no handle plexus requirement
> > > without filed-name set.
> > >
> > > The -Dplexus-spring.debug=true option can be used to dump the
> > > translated spring XML (using dom4j)
> > >
> > > PlexusInSpringTestCase as been used as replacement for PlexusTestCase
> > > in archiva-policies with no other change required in the test class (only 
> > > a
> > > new spring context file required to declare the LoggerManager)
> > >
> > > Some debugging logs have been added to trace the filed-injection and
> > > dependencies resolution.
> > >
> > >
> > > .. but still not ready as
> > > CacheFailuresTransferTest.testGetWithCacheFailuresOff pass run alone,
> > > but not if ran after testGetWithCacheFailuresOn!
> > > Seems there is some incomplete support on context cleanup / dispose
> > >
> > > Please be patient, Rahul ;-)
> > >
> > > Nico.
> > >
> > >
> > >
> > > 2008/2/26, Joakim Erdfelt <[EMAIL

Re: [VOTE] Request Archiva graduation to a TLP

[nicolas de loof]

+1

2008/2/28, Brett Porter <[EMAIL PROTECTED]>:
>
> +1
>
>
> On 28/02/2008, at 9:11 PM, 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])
> > Maria Odea Ching ([EMAIL PROTECTED])
> > Nicolas de Loof ([EMAIL PROTECTED])
> > Joakim Erdfelt ([EMAIL PROTECTED])
> > Arnaud Heritier ([EMAIL PROTECTED])
> > Dennis Lundberg ([EMAIL PROTECTED])
> > Jesse McConnell ([EMAIL PROTECTED])
> > Brett Porter ([EMAIL PROTECTED])
> > Edwin Punzalan ([EMAIL PROTECTED])
> > Carlos Sanchez ([EMAIL PROTECTED])
> > Wendy Smoak ([EMAIL PROTECTED])
> > John Tolentino ([EMAIL PROTECTED])
> > Emmanuel Venisse ([EMAIL PROTECTED])
> >
> > 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.
>
>
> --
>
> Brett Porter
> [EMAIL PROTECTED]
>
> http://blogs.exist.com/bporter/
>
>

Re: from plexus to spring...

[nicolas de loof]

For your information, plexus-spring no handle plexus requirement without
filed-name set.

The -Dplexus-spring.debug=true option can be used to dump the translated
spring XML (using dom4j)

PlexusInSpringTestCase as been used as replacement for PlexusTestCase in
archiva-policies with no other change required in the test class (only a new
spring context file required to declare the LoggerManager)

Some debugging logs have been added to trace the filed-injection and
dependencies resolution.


.. but still not ready as
CacheFailuresTransferTest.testGetWithCacheFailuresOff pass run alone, but
not if ran after testGetWithCacheFailuresOn!
Seems there is some incomplete support on context cleanup / dispose

Please be patient, Rahul ;-)

Nico.



2008/2/26, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> 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: from plexus to spring...

[nicolas de loof]

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: from plexus to spring...

[nicolas de loof]

archiva-proxy CacheFailuresTransferTest and archiva-policies
CachedFailuresPolicyTest no pass running under spring applicationContext.

I've added a minimal Contextualizable support for components that do lookup
in the plexusContainer.

Some more work required to build full archiva with spring ;-)

2008/2/25, nicolas de loof <[EMAIL PROTECTED]>:
>
>
> > >
> > > This makes things more complex on the spring side. Is this a common
> > > use case
> > > or can we live without this feature ?
> >
> >
> > If that's not doable, can we throw an unsupported exception if it's
> > not given?
>
>
> An ApplicationContextException is thrown in such case on current codebase.
> I will investigate on supporting this feature if required. This doesn't seem
> so complex : iterate on fields an search the one that matches the
> requirement type...
>
> Nicolas.
>
>
> >
> > >
> > > I've found the bug in archiva-proxy CacheFailuresTransferTest :
> > > there was
> > > some plexus to spring mistakes, but the final issue is the
> > > requirement on
> > > RepositoryContentFactory for the Contextualizable interface, and
> > > direct
> > > access to the PlexusContainer.
> > >
> > > I plan to create a PlexusContainerAdapter to expose Spring beans
> > >
> > > Nicolas.
> > >
> > > 2008/2/25, Brett Porter <[EMAIL PROTECTED]>:
> > >>
> > >>
> > >> On 25/02/2008, at 10:23 PM, nicolas de loof wrote:
> > >>
> > >>> Can someone confirm the plexus behavior for IoC :
> > >>>
> > >>> When the target field is a Map or a Collection and no role-hint is
> > >>> specified, inject all component implementations
> > >>>
> > >>> When the target field is the component interface and no role-hint is
> > >>> specified, inject the no-hint component or the one with rol-hint
> > >>> "default".
> > >>
> > >>
> > >> Correct.
> > >>
> > >>
> > >>>
> > >>>
> > >>> Is there a special handling for "mock" role-hint ? I have some
> > >>> issues with
> > >>> component initialisation in archiva-proxy CacheFailureTransfertTest
> > >>> that
> > >>> seems to be related to MockArchivaConfiguration...
> > >>
> > >>
> > >> No - are you reading the CacheFailureTransferTest.xml file as a
> > >> plexus
> > >> descriptor?
> > >>
> > >> - Brett
> > >>
> > >>
> > >> --
> > >> Brett Porter
> > >> [EMAIL PROTECTED]
> > >> http://blogs.exist.com/bporter/
> > >>
> > >>
> >
> > --
> > Brett Porter
> > [EMAIL PROTECTED]
> > http://blogs.exist.com/bporter/
> >
> >
>

Re: from plexus to spring...

[nicolas de loof]

>
>
> >
> > This makes things more complex on the spring side. Is this a common
> > use case
> > or can we live without this feature ?
>
>
> If that's not doable, can we throw an unsupported exception if it's
> not given?


An ApplicationContextException is thrown in such case on current codebase. I
will investigate on supporting this feature if required. This doesn't seem
so complex : iterate on fields an search the one that matches the
requirement type...

Nicolas.


>
> >
> > I've found the bug in archiva-proxy CacheFailuresTransferTest :
> > there was
> > some plexus to spring mistakes, but the final issue is the
> > requirement on
> > RepositoryContentFactory for the Contextualizable interface, and
> > direct
> > access to the PlexusContainer.
> >
> > I plan to create a PlexusContainerAdapter to expose Spring beans
> >
> > Nicolas.
> >
> > 2008/2/25, Brett Porter <[EMAIL PROTECTED]>:
> >>
> >>
> >> On 25/02/2008, at 10:23 PM, nicolas de loof wrote:
> >>
> >>> Can someone confirm the plexus behavior for IoC :
> >>>
> >>> When the target field is a Map or a Collection and no role-hint is
> >>> specified, inject all component implementations
> >>>
> >>> When the target field is the component interface and no role-hint is
> >>> specified, inject the no-hint component or the one with rol-hint
> >>> "default".
> >>
> >>
> >> Correct.
> >>
> >>
> >>>
> >>>
> >>> Is there a special handling for "mock" role-hint ? I have some
> >>> issues with
> >>> component initialisation in archiva-proxy CacheFailureTransfertTest
> >>> that
> >>> seems to be related to MockArchivaConfiguration...
> >>
> >>
> >> No - are you reading the CacheFailureTransferTest.xml file as a
> >> plexus
> >> descriptor?
> >>
> >> - Brett
> >>
> >>
> >> --
> >> Brett Porter
> >> [EMAIL PROTECTED]
> >> http://blogs.exist.com/bporter/
> >>
> >>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

Re: from plexus to spring...

[nicolas de loof]

On plexus XML descriptors, the  seems to be optional...  (
CacheFailuresTransferTest.xml)
This makes things more complex on the spring side. Is this a common use case
or can we live without this feature ?

I've found the bug in archiva-proxy CacheFailuresTransferTest : there was
some plexus to spring mistakes, but the final issue is the requirement on
RepositoryContentFactory for the Contextualizable interface, and direct
access to the PlexusContainer.

I plan to create a PlexusContainerAdapter to expose Spring beans

Nicolas.

2008/2/25, Brett Porter <[EMAIL PROTECTED]>:
>
>
> On 25/02/2008, at 10:23 PM, nicolas de loof wrote:
>
> > Can someone confirm the plexus behavior for IoC :
> >
> > When the target field is a Map or a Collection and no role-hint is
> > specified, inject all component implementations
> >
> > When the target field is the component interface and no role-hint is
> > specified, inject the no-hint component or the one with rol-hint
> > "default".
>
>
> Correct.
>
>
> >
> >
> > Is there a special handling for "mock" role-hint ? I have some
> > issues with
> > component initialisation in archiva-proxy CacheFailureTransfertTest
> > that
> > seems to be related to MockArchivaConfiguration...
>
>
> No - are you reading the CacheFailureTransferTest.xml file as a plexus
> descriptor?
>
> - Brett
>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

Re: from plexus to spring...

[nicolas de loof]

Can someone confirm the plexus behavior for IoC :

When the target field is a Map or a Collection and no role-hint is
specified, inject all component implementations

When the target field is the component interface and no role-hint is
specified, inject the no-hint component or the one with rol-hint "default".

Is there a special handling for "mock" role-hint ? I have some issues with
component initialisation in archiva-proxy CacheFailureTransfertTest that
seems to be related to MockArchivaConfiguration...

Nicolas.


2008/2/25, nicolas de loof <[EMAIL PROTECTED]>:
>
> 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.
>

from plexus to spring...

[nicolas de loof]

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: An experiment with Spring

[nicolas de loof]

I've asked springsource guys for help on this topic.

I sent Chris Beams <[EMAIL PROTECTED]> a simplified project with
testcase to investigate.

Nico.


2008/2/22, Brett Porter <[EMAIL PROTECTED]>:
>
> Wow, that's cool. :)
>
> On 22/02/2008, at 3:38 AM, nicolas de loof wrote:
>
> > Work in progress ...
> >
> > I've created a PlexusClassPathXmlApplicationContext that accept both
> > Spring
> > context files and plexus descriptors as resources.
> >
> > I also enhanced the XSLT to declare a bean alias for plexus
> > components :
> >
> > - plexus roles are by convention the FQCN of the interface
> > - spring IDs are by convention the simple interface class name with
> > lowercase first char
> >
> > the XSL now declares a spring-convention alias for the plexus role,
> > that is
> > used as bean ID, so that the same bean can be safely requested from
> > a plexus
> > component (by role using @plexus.requirement), or from a spring bean
> > by ID.
> >
> > I've made required changes to apply this to CachedFailuresPolicyTest
> >
> > I still have an issue to enable field injection with Spring
> > beanfactory,
> > that (unofficialy ?) supports this feature (for EJB3 injection) but
> > requires
> > some conf ...
> >
> > I've posted on spring forum :
> > http://forum.springframework.org/showthread.php?t=50181
> >
> > 2008/2/20, Brett Porter <[EMAIL PROTECTED]>:
> >>
> >> This is way cooler than what I was doing :)
> >>
> >> Can you replace the calls to the other factories so we can see this
> >> in
> >> action with a spring bean and plexus component all wired up?
> >>
> >> I wouldn't worry about the portability for now - maybe if it were
> >> donated to Plexus itself that'd require some revision.
> >>
> >> Cheers,
> >>
> >> Brett
> >>
> >>
> >> On 21/02/2008, at 2:31 AM, nicolas de loof wrote:
> >>
> >>> I just added support for camelCase properties names using Xalan
> >>> extension.
> >>>
> >>> I don't know how to register a custom XpathFunction to a standard
> >>> Trax
> >>> Transformer. This will be required to make code fully portable, or
> >>> maybe we
> >>> can hard-code the use of Xalan in place of Trax API.
> >>>
> >>> Nico.
> >>>
> >>> 2008/2/20, nicolas de loof <[EMAIL PROTECTED]>:
> >>>>
> >>>> I commited on the branch a first attempt to convert plexus
> >>>> descriptor to
> >>>> spring context based on XSLT.
> >>>>
> >>>> Only basic convertion is supported yet.
> >>>>
> >>>> converting elements in  to camelCase properties
> >>>> would
> >>>> require either some advanced XSLT, either a spring bean post-
> >>>> processor
> >>>> (maybe the simpliest !)
> >>>>
> >>>> Support for plexus lifecycle in Spring could be handled by a
> >>>> BeanPostProcessor to detect bean types to implement Plexus
> >>>> interfaces and
> >>>> setup the required init/destroy-methods.
> >>>>
> >>>> Nicolas.
> >>>>
> >>>>
> >>>> 2008/2/20, nicolas de loof <[EMAIL PROTECTED]>:
> >>>>>
> >>>>> Could'nt Spring mimic the PlexusContainer ?
> >>>>>
> >>>>> Archiva-webapp can be started with a spring context with support
> >>>>> from
> >>>>> webwork/struts2 for IoC. We 'just' have to help the spring context
> >>>>> retrieve
> >>>>> the components declared in plexus context files.
> >>>>>
> >>>>> As spring and plexus IoC concepts are equivalent, we could use a
> >>>>> custom
> >>>>> ApplicationContext to parse plexus components.xml, and handle
> >>>>> plexus
> >>>>> lifecycle interfaces.
> >>>>>
> >>>>> It's not trivial, but not so difficult - it's only good old XML
> >>>>> parsing... and some spring internals.
> >>>>>
> >>>>> On this basis, we can migrate components in isolation, without
> >>>>> requirement for changes in many places because some other
> >>>>>

Re: An experiment with Spring

[nicolas de loof]

I just added support for camelCase properties names using Xalan extension.

I don't know how to register a custom XpathFunction to a standard Trax
Transformer. This will be required to make code fully portable, or maybe we
can hard-code the use of Xalan in place of Trax API.

Nico.

2008/2/20, nicolas de loof <[EMAIL PROTECTED]>:
>
> I commited on the branch a first attempt to convert plexus descriptor to
> spring context based on XSLT.
>
> Only basic convertion is supported yet.
>
> converting elements in  to camelCase properties would
> require either some advanced XSLT, either a spring bean post-processor
> (maybe the simpliest !)
>
> Support for plexus lifecycle in Spring could be handled by a
> BeanPostProcessor to detect bean types to implement Plexus interfaces and
> setup the required init/destroy-methods.
>
> Nicolas.
>
>
> 2008/2/20, nicolas de loof <[EMAIL PROTECTED]>:
> >
> > Could'nt Spring mimic the PlexusContainer ?
> >
> > Archiva-webapp can be started with a spring context with support from
> > webwork/struts2 for IoC. We 'just' have to help the spring context retrieve
> > the components declared in plexus context files.
> >
> > As spring and plexus IoC concepts are equivalent, we could use a custom
> > ApplicationContext to parse plexus components.xml, and handle plexus
> > lifecycle interfaces.
> >
> > It's not trivial, but not so difficult - it's only good old XML
> > parsing... and some spring internals.
> >
> > On this basis, we can migrate components in isolation, without
> > requirement for changes in many places because some other component has (or
> > has not yet) been updated to use spring.
> >
> > Nico.
> >
> > 2008/2/20, Brett Porter <[EMAIL PROTECTED]>:
> > >
> > > On 20/02/2008, at 6:33 PM, nicolas de loof wrote:
> > >
> > > > What about a Combined Plexus context, where the lookup method both
> > > > search in
> > > > the plexus components and the springFactory ?
> > > >
> > > > This would make initialization more complex, but we could use @
> > > > plexus.requirement as is to get spring beans without having to know
> > > > they are
> > > > managed by spring.
> > >
> > > If we think we have a long term requirement for this, then that makes
> > > a lot of sense - and in fact Carlos did something similar for
> > > Continuum with an acegi experiment once I believe.
> > >
> > > OTOH - since Archiva is a standalone app it would be best to be
> > > consistent across it since we have that freedom. And actually, because
> > > of the built-in support in webwork and struts2 for spring IOC, the web
> > > layer is the easiest to change if everything else is already migrated,
> > > so there'll be no need for the app itself to primarily be a Plexus run
> > > app (though it might still have some plexus components we'll want to
> > > pick up).
> > >
> > > Cheers,
> > > Brett
> > >
> > > --
> > > Brett Porter
> > > [EMAIL PROTECTED]
> > > http://blogs.exist.com/bporter/
> > >
> > >
> >
>

Re: An experiment with Spring

[nicolas de loof]

I commited on the branch a first attempt to convert plexus descriptor to
spring context based on XSLT.

Only basic convertion is supported yet.

converting elements in  to camelCase properties would require
either some advanced XSLT, either a spring bean post-processor (maybe the
simpliest !)

Support for plexus lifecycle in Spring could be handled by a
BeanPostProcessor to detect bean types to implement Plexus interfaces and
setup the required init/destroy-methods.

Nicolas.


2008/2/20, nicolas de loof <[EMAIL PROTECTED]>:
>
> Could'nt Spring mimic the PlexusContainer ?
>
> Archiva-webapp can be started with a spring context with support from
> webwork/struts2 for IoC. We 'just' have to help the spring context retrieve
> the components declared in plexus context files.
>
> As spring and plexus IoC concepts are equivalent, we could use a custom
> ApplicationContext to parse plexus components.xml, and handle plexus
> lifecycle interfaces.
>
> It's not trivial, but not so difficult - it's only good old XML parsing...
> and some spring internals.
>
> On this basis, we can migrate components in isolation, without requirement
> for changes in many places because some other component has (or has not yet)
> been updated to use spring.
>
> Nico.
>
> 2008/2/20, Brett Porter <[EMAIL PROTECTED]>:
> >
> > On 20/02/2008, at 6:33 PM, nicolas de loof wrote:
> >
> > > What about a Combined Plexus context, where the lookup method both
> > > search in
> > > the plexus components and the springFactory ?
> > >
> > > This would make initialization more complex, but we could use @
> > > plexus.requirement as is to get spring beans without having to know
> > > they are
> > > managed by spring.
> >
> > If we think we have a long term requirement for this, then that makes
> > a lot of sense - and in fact Carlos did something similar for
> > Continuum with an acegi experiment once I believe.
> >
> > OTOH - since Archiva is a standalone app it would be best to be
> > consistent across it since we have that freedom. And actually, because
> > of the built-in support in webwork and struts2 for spring IOC, the web
> > layer is the easiest to change if everything else is already migrated,
> > so there'll be no need for the app itself to primarily be a Plexus run
> > app (though it might still have some plexus components we'll want to
> > pick up).
> >
> > Cheers,
> > Brett
> >
> > --
> > Brett Porter
> > [EMAIL PROTECTED]
> > http://blogs.exist.com/bporter/
> >
> >
>

Re: An experiment with Spring

[nicolas de loof]

Could'nt Spring mimic the PlexusContainer ?

Archiva-webapp can be started with a spring context with support from
webwork/struts2 for IoC. We 'just' have to help the spring context retrieve
the components declared in plexus context files.

As spring and plexus IoC concepts are equivalent, we could use a custom
ApplicationContext to parse plexus components.xml, and handle plexus
lifecycle interfaces.

It's not trivial, but not so difficult - it's only good old XML parsing...
and some spring internals.

On this basis, we can migrate components in isolation, without requirement
for changes in many places because some other component has (or has not yet)
been updated to use spring.

Nico.

2008/2/20, Brett Porter <[EMAIL PROTECTED]>:
>
> On 20/02/2008, at 6:33 PM, nicolas de loof wrote:
>
> > What about a Combined Plexus context, where the lookup method both
> > search in
> > the plexus components and the springFactory ?
> >
> > This would make initialization more complex, but we could use @
> > plexus.requirement as is to get spring beans without having to know
> > they are
> > managed by spring.
>
> If we think we have a long term requirement for this, then that makes
> a lot of sense - and in fact Carlos did something similar for
> Continuum with an acegi experiment once I believe.
>
> OTOH - since Archiva is a standalone app it would be best to be
> consistent across it since we have that freedom. And actually, because
> of the built-in support in webwork and struts2 for spring IOC, the web
> layer is the easiest to change if everything else is already migrated,
> so there'll be no need for the app itself to primarily be a Plexus run
> app (though it might still have some plexus components we'll want to
> pick up).
>
> Cheers,
> Brett
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

Re: An experiment with Spring

[nicolas de loof]

What about a Combined Plexus context, where the lookup method both search in
the plexus components and the springFactory ?

This would make initialization more complex, but we could use @
plexus.requirement as is to get spring beans without having to know they are
managed by spring.

Nico.

2008/2/20, Brett Porter <[EMAIL PROTECTED]>:
>
> Hi,
>
> Given the discussion yesterday, I played around with some changes on a
> branch when I got up early this morning to show how we could do a
> partial migration to Spring without having to do it all at once.
>
> https://svn.apache.org/repos/asf/maven/archiva/branches/springy
>
> This shows:
> - ability to lookup plexus components via spring IoC
> - ability to lookup spring beans during the Plexus component lifecycle
> - basic functional setup for Spring in the Archiva application
>
> Eventually, as whole subsystems no longer require plexus it will be
> possible to clean it up, such as:
> - get rid of the additional lookups
> - use annotations for configuration
> - use testng + get/set + mocks for the tests where possible (and
> spring testcontext where integration testing is needed)
>
> Here is how to obtain a plexus object from Spring (note there is some
> pre-req setup in test cases you'll see in the commit, as there is in
> the additional servlet listener):
> method="createInstance" />
> class="org.apache.maven.archiva.common.spring.PlexusFactory">
>   value="org.codehaus.plexus.cache.Cache"/>
>  
>
>
> To get a spring bean inside a plexus component, it is like this (make
> sure to implement Initializable):
>
>  /**
>   * @plexus.requirement
>   */
>  private SpringFactory springFactory;
>
>  public void initialize()
>  throws InitializationException
>  {
>  urlFailureCache = (UrlFailureCache)
> springFactory.lookup( "urlFailureCache" );
>  }
>
> The next thing we should probably try is using something like
> SpringCache as suggested to remove the plexus-cache dependency.
>
> Have fun!
>
> Cheers,
> Brett
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>

Re: Plan to migrate towards Spring?

[nicolas de loof]

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


2008/2/19, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> On Feb 19, 2008 11:23 AM, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
>
> > 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.
> >
>
> Yeah, this is very likely to happen..
>
>
> >
> > 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.
>
>
> +1 on Spring Caching
>
>
> >
> >
> > >
> > >> 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?
>
>
> I don't think the webapp-tests ever got updated in parallel with any of
> our
> releases (even the alpha & beta releases), so a lot of work would have to
> be
> put here if we're going to limp it along..
>
>
> >
> > >
> > >>
> > >> 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.p

Re: Plan to migrate towards Spring?

[nicolas de loof]

About "Create alternative descriptors to use Spring for existing codebase."

We could create a maven plugin (similar to plexus one) to parse sources and
get Spring IoC annotations converted to plexus XML config (something like
springdoclet). It may also convert spring XML context to plexus
component.xml .

Based on this we could keep the plexus-based infrastructure until all
components have been migrated to use Spring, and then switch.

Nico.


2008/2/19, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> 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.code

Re: Archiva 1.1 Roadmap

[nicolas de loof]

Not sure about this as I didn't experiment, but what's maven behaviour when
accessing a repository configured with snapshots=disabled and receiving
meta-datas with snapshots ?

The idea is :

in my settings.xml, configure archiva for mirroOf=*, and have a "grouped"
archiva repository , that groups all my repos (snapshots & releases)

when maven request a released artifact all is fine.
when maven request a snapshot and reads meta-datas, it should get the latest
snapshot

The only possible issue here (AFAIK) is that I could get a snapshot for a
plugin when there is no version set in the POM. As I have set all commons
plugins version in my corporate POM , I'm safe with this
(I can also use a maven-enforcer-plugin rule for this).

Using such a config (if we supose there is no side-effect), what is the
benefict of having separate release and snapshot repositories ?

Nico.

2008/2/5, Arnaud HERITIER <[EMAIL PROTECTED]>:
>
> I had also this idea of virtual repositories (i talk with brett about it
> some monthes ago) because it simplify user settings and moreover it
> reduces
> the bandwith and the access time if the network isn't really good. Maven
> has
> to do only one request for each artifact.
> For snapshots and dependencies with a range it's less easy to develop
> because you have to check in all repositories to see where is the newest
> version.
> Another problem is that I would like to have like nicolas only two
> repositories  : one for snapshots and one for releases. But actually in
> the
> maven side I can't have a mirror * for snapshots and another for releases.
>
> Arnaud
>
> On Feb 5, 2008 9:03 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> > Yes, that's the idea of a "vitrual" repository URL to acces a set
> > ("group")
> > of managed repositories.
> >
> > For my personnal use case I also have to look at the Dav server
> > implementation to add support for Windows UNC file path.
> >
> > Nico.
> >
> > 2008/2/5, Maria Odea Ching <[EMAIL PROTECTED]>:
> > >
> > > Hi Nicolas,
> > >
> > > I believe what you were pertaining in your scenario is like the
> > repository
> > > grouping? Where in a number of managed repositories can  be grouped
> > > together
> > > with that group having only one url. So you only need to specify that
> > url
> > > in
> > > your settings.xml file and when Archiva receives a request via that
> url,
> > > it
> > > would look for that artifact from the repositories belonging to that
> > > group.
> > >
> > > This functionality is really handy especially if the users are not
> very
> > > familiar with Maven as in your corporate use-case..
> > >
> > > Thanks,
> > > Deng
> > >
> > > On Feb 4, 2008 6:58 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > >
> > > > My "managed" repository are on another windows Box (for corporate
> > > reason)
> > > > and are proxied as file:// URLs.
> > > > I have to manage them by hand as the DAV server doesn't support
> > windows
> > > > SMB
> > > > file format "\\server\path" (that gets "normalized" to
> > "\server\path").
> > > > That's not an issue for me as there is nothing to manage (only
> > sometime
> > > > deploy new artifacts).
> > > >
> > > > My "maven" managed repository duplicates those corporate repos, and
> > also
> > > > mirors public internet ones.
> > > >
> > > > I only use archiva as a proxy and cache, so don't care about
> > > scanner-based
> > > > features on my corporate repos. Hand based management is enough for
> me
> > > on
> > > > those one. If I configure them as managed repos, I may get artifact
> > > twice
> > > > on
> > > > browse ... to be honest I also don't use the browse feature !
> > > >
> > > > For my use case, archiva is just a replacement of the good old
> > > maven-proxy
> > > > I
> > > > used for maven1, with the HUGE benefict I can manage a single maven2
> > > > repository and still have my old m1 projects (I still have lots) get
> > the
> > > > required artifacts.
> > > >
> > > > I have a second "managed" repository for snapshots as
> > > > http://server/archiva/repository/snapshot with the required 
> > in
> > > > settings.x

Re: Archiva 1.1 Roadmap

[nicolas de loof]

My "managed" repository are on another windows Box (for corporate reason)
and are proxied as file:// URLs.
I have to manage them by hand as the DAV server doesn't support windows SMB
file format "\\server\path" (that gets "normalized" to "\server\path").
That's not an issue for me as there is nothing to manage (only sometime
deploy new artifacts).

My "maven" managed repository duplicates those corporate repos, and also
mirors public internet ones.

I only use archiva as a proxy and cache, so don't care about scanner-based
features on my corporate repos. Hand based management is enough for me on
those one. If I configure them as managed repos, I may get artifact twice on
browse ... to be honest I also don't use the browse feature !

For my use case, archiva is just a replacement of the good old maven-proxy I
used for maven1, with the HUGE benefict I can manage a single maven2
repository and still have my old m1 projects (I still have lots) get the
required artifacts.

I have a second "managed" repository for snapshots as
http://server/archiva/repository/snapshot with the required  in
settings.xml for apache.snapshots & codehaus.snapshots

This configuration is simple for user but not very clean on server side. I
can't take advantage of archiva features on my managed repos (even I don't
need/use them now, they still are interesting).

The  "virtual repository" concept would solve the configuration issue but
not my "unsuported samba share filesystem" issue :-(

Nico.

2008/2/4, Fabrice Bellingard <[EMAIL PROTECTED]>:
>
> Nicolas,
>
> concerning your "maven" managed repository: are you currently really doing
> that with archiva? It seems indeed interesting, as it simplifies the
> configuration of the settings.xml file. However, I have a couple of
> questions:
> - this means that this "maven" repository duplicates every artifact
> handled
> in your other managed repositories, right? So when you browse artifacts in
> Archiva, you see managed artifacts twice, don't you?
> - do you use the same principle for snapshots repositories? I mean,
> metadata
> files would conflict with release repositories, so you need another
> "virtual" repository for snapshots.
>
> Fabrice
>
> On Feb 4, 2008 9:38 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> > Early version of archiva had on admin menu a "sync repository" entry.
> >
> > Not sure if the original idea was to manage a classical rsync-like miror
> > or
> > to isolate local cache for remote proxied repositories.
> >
> >
> > I would suggest some "virtual" repository
> >
> > A simple example is my corporate use case : many user don't know maven
> > well
> > and have no idea what a repository is (and how to configure), so we have
> > configured settings.xml to mirror all common repositories to the archiva
> > instance : http://server/archiva/repository/maven
> >
> > The "maven" managed repository is an aggregate of proxied (central,
> > java.net,
> > jboss, ...) and managed ones : corporate builds, restricted jars (SUN
> > apis,
> > oracle driver) and sources bundles (missing in public repos)
> >
> > This repository, declared in archiva configuration as "managed" is NOT
> the
> > one we have to manage ! It only is a facade to other managed and proxied
> > repositories.
> >
> >
> > Nico.
> >
> > > >
> > > > One item I wanted to single out is the separation between managed
> > > > repositories used for publishing and those used for caching
> artifacts
> > > > from remote repositories. I don't think it makes much sense to have
> a
> > > > managed repository that can do both.
> > >
> > >
> > > a big +1 here :) a lot of people has been confused over this
> especially
> > > when
> > > there are quite a handful of repositories being managed.
> > >
> > >
> > > >
> > > >
> > > > This separation would allow us to have:
> > > > * Provide indexing, browsing and search only for "publishing" (See
> > foot
> > > > note)
> > > > * RSS feeds for new artifacts in published repositories.
> > > >
> > > > Foot note:
> > > > Allowing to search proxied data is a broken idea - its an incomplete
> > > > view of a remote repositories and when your dealing with tens of
> > > > gigabytes of metadata and artifacts this becomes painful and slow.
> > > >
> > > > Anyway, I look forward to your comments.
> > > >
> > > > Thanks,
> > > > James Dumay
> > > >
> > > >
> > > Thanks,
> > > Deng
> > >
> >
>

Re: [VOTE] Release Archiva 1.0.1 (Take 2)

[nicolas de loof]

+1

still some known minor issues to be fully m1 compliant (ejb type).

Nico

2008/1/30, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> Here's my +1 :)
> Had it running the whole day today and it's working quite nicely..
>
> Thanks,
> Deng
>
> On Jan 29, 2008 7:11 PM, Maria Odea Ching <[EMAIL PROTECTED]> wrote:
>
> > Hi Everyone,
> >
> > The Archiva 1.0.1 release candidate has been prepared. JPOX was upgraded
> > from 1.1.7 to 1.1.9 to fix an issue that results for Archiva to hang.
> > Other changes for this release include an improvement for maven 1
> artifact
> > resolution, validation in the legacy artifact mapping form and revisions
> in
> > the documentation.
> >
> > You can take a look at the release notes for Archiva 1.0.1 here:
> >
> >
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13925&styleName=Text&projectId=10980&Create=Create
> >
> > The binaries, including the sources, signatures and checksums can be
> > downloaded here:
> >
> > http://people.apache.org/builds/maven/archiva/1.0.1/
> >
> >
> > And the archiva-parent pom is staged here:
> >
> >
> >
> http://people.apache.org/~oching/stage-repo/org/apache/maven/archiva/archiva-parent/2/
> <
> http://people.apache.org/%7Eoching/stage-repo/org/apache/maven/archiva/archiva-parent/2/
> >
> >
> >
> > Everyone is encouraged to vote and give their feedback. Please make sure
> > to test it before voting ;-)
> >
> > [ ]  +1  Release it!
> > [ ]   0
> > [ ]  -1  Don't release it, because...
> >
> > The vote will be open for 72 hours. So, cast your votes now..
> >
> > Thanks,
> > Deng
> >
> >
>

Re: jpox repository ?

[nicolas de loof]

I also notice archiva-model is using jpox 1.1.6 plugin from Mojo

Is there a reason not to use jpox-one :
http://www.jpox.org/downloads/maven2/jpox/jpox-maven-plugin/

Nico.

2008/1/30, nicolas de loof <[EMAIL PROTECTED]>:
>
> MVNII-14 was closed as "Won't fix"
> The central POM is a converted from m1 POM, jPox also has a valid POM in
> SVN
>
> That also shows that the m1 -> m2 pom conversion doesn't work well and
> produces invalid POMs.
> Maybe this process should be enhance to validate the converted POM before
> deployment, and maybe slip it if non convertible.
>
> Nico.
>
>
> 2008/1/30, Wendy Smoak <[EMAIL PROTECTED]>:
> >
> > On Jan 30, 2008 8:18 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > > Is there a good reason to declare jpox-repository in archiva main pom
> > ?
> > >
> > > The jpox pom.xml is a maven1 pom, and the requested artifact is
> > available in
> > > central.
> >
> > I think it was added while we waited for jpox 1.1.9 to be uploaded [1]
> > and it can be removed now.
> >
> > [1] http://jira.codehaus.org/browse/MEV-566
> >
> > --
> > Wendy
> >
>
>

Re: jpox repository ?

[nicolas de loof]

MVNII-14 was closed as "Won't fix"
The central POM is a converted from m1 POM, jPox also has a valid POM in SVN

That also shows that the m1 -> m2 pom conversion doesn't work well and
produces invalid POMs.
Maybe this process should be enhance to validate the converted POM before
deployment, and maybe slip it if non convertible.

Nico.


2008/1/30, Wendy Smoak <[EMAIL PROTECTED]>:
>
> On Jan 30, 2008 8:18 AM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > Is there a good reason to declare jpox-repository in archiva main pom ?
> >
> > The jpox pom.xml is a maven1 pom, and the requested artifact is
> available in
> > central.
>
> I think it was added while we waited for jpox 1.1.9 to be uploaded [1]
> and it can be removed now.
>
> [1] http://jira.codehaus.org/browse/MEV-566
>
> --
> Wendy
>

Re: jpox repository ?

[nicolas de loof]

That beeing said, jpox m2 POM is also invalid :

Validation Messages:

[0]  'dependencies.dependency.version' is missing for oracle:ojdbc


  oracle
  ojdbc



I've created MVNII-14 on www.jpox.org, if anyone here also works on this
project...

Nico.


2008/1/30, nicolas de loof <[EMAIL PROTECTED]>:
>
> Is there a good reason to declare jpox-repository in archiva main pom ?
>
> The jpox pom.xml is a maven1 pom, and the requested artifact is available
> in central.
>
> Nico.
>

Re: svn commit: r610753 - in /maven/archiva/trunk/archiva-base: archiva-configuration/ archiva-configuration/src/main/mdo/ archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/ a

[nicolas de loof]

update done.

sorry for this.


2008/1/11, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> Hi again Nicolas,
>
> There seems to be a class in archiva-webapp module which uses the
> getArtifactReference() in LegacyPathArtifact that you removed from
> configuration.mdo. Could you roll back the changes please? or update the
> webapp module? :)
>
> Thanks,
> Deng
>
> On Jan 10, 2008 6:54 PM, <[EMAIL PROTECTED]> wrote:
>
> > Author: nicolas
> > Date: Thu Jan 10 02:54:32 2008
> > New Revision: 610753
> >
> > URL: http://svn.apache.org/viewvc?rev=610753&view=rev
> > Log:
> > remove dependency between archiva-configuration and archiva-model
> >
> > Modified:
> >maven/archiva/trunk/archiva-base/archiva-configuration/pom.xml
> >
>
> >  
> > maven/archiva/trunk/archiva-base/archiva-configuration/src/main/mdo/configuration.mdo
> >
>
> >  
> > maven/archiva/trunk/archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/LegacyArtifactPathTest.java
> >
>
> >  
> > maven/archiva/trunk/archiva-base/archiva-repository-layer/src/main/java/org/apache/maven/archiva/repository/content/LegacyPathParser.java
> >
> > Modified: maven/archiva/trunk/archiva-base/archiva-configuration/pom.xml
> > URL:
> >
> http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-configuration/pom.xml?rev=610753&r1=610752&r2=610753&view=diff
> >
> >
> ==
> > --- maven/archiva/trunk/archiva-base/archiva-configuration/pom.xml
> > (original)
> > +++ maven/archiva/trunk/archiva-base/archiva-configuration/pom.xml Thu
> Jan
> > 10 02:54:32 2008
> > @@ -37,10 +37,6 @@
> >   archiva-policies
> > 
> > 
> > -  org.apache.maven.archiva
> > -  archiva-model
> > -
> > -
> >   org.codehaus.plexus
> >   plexus-component-api
> > 
> >
> > Modified:
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/main/mdo/configuration.mdo
> > URL:
> >
> http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-configuration/src/main/mdo/configuration.mdo?rev=610753&r1=610752&r2=610753&view=diff
> >
> >
> ==
> > ---
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/main/mdo/configuration.mdo
> > (original)
> > +++
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/main/mdo/configuration.mdo
> > Thu Jan 10 02:54:32 2008
> > @@ -473,19 +473,30 @@
> > return path.equals( this.path );
> > }
> >
> > -public
> org.apache.maven.archiva.model.ArtifactReferencegetArtifactReference()
> > +public String getGroupId()
> > {
> > -org.apache.maven.archiva.model.ArtifactReference reference =
> new
> > org.apache.maven.archiva.model.ArtifactReference();
> > -String[] parts = artifact.split( ":" );
> > -reference.setGroupId( parts[0] );
> > -reference.setArtifactId( parts[1] );
> > -reference.setVersion( parts[2] );
> > -if ( parts[3].length() > 0 )
> > -{
> > -reference.setClassifier( parts[3] );
> > -}
> > -reference.setType( parts[4] );
> > -return reference;
> > +return artifact.split( ":" )[0];
> > +   }
> > +
> > +public String getArtifactId()
> > +{
> > +return artifact.split( ":" )[1];
> > +   }
> > +
> > +public String getVersion()
> > +{
> > +return artifact.split( ":" )[2];
> > +   }
> > +
> > +public String getClassifier()
> > +{
> > +   String classifier = artifact.split( ":" )[3];
> > +return classifier.length() > 0 ? classifier : null;
> > +   }
> > +
> > +public String getType()
> > +{
> > +return artifact.split( ":" )[4];
> > }
> >]]>
> > 
> >
> > Modified:
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/LegacyArtifactPathTest.java
> > URL:
> >
> http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/LegacyArtifactPathTest.java?rev=610753&r1=610752&r2=610753&view=diff
> >
> >
> ==
> > ---
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/LegacyArtifactPathTest.java
> > (original)
> > +++
> >
> maven/archiva/trunk/archiva-base/archiva-configuration/src/test/java/org/apache/maven/archiva/configuration/LegacyArtifactPathTest.java
> > Thu Jan 10 02:54:32 2008
> > @@ -2,8 +2,6 @@
> >
> >  import junit.framework.TestCase;
> >
> > -import org.apache.maven.archiva.model.ArtifactReference;
> > -
> >  /*
> >  * Licensed to the Apache Software Foundation (ASF) under one
> >  * or more contributor license agreements.  See the NOTICE file
> > @@ -37,12 +35,11 @@
> > {
> > legacyArtifactP

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

[nicolas de loof]

I've reverted my change.

The cacheUrlFailure is not set on an "one-instance-per-connector" basis and
using it has for side effect to break the test expectation.
I missunderstood what it was designed for, and am not familiar enought with
plexus to change the cacheFailure nature to a "prototype" (using Spring
vocabulary).

Nico.


2008/1/11, Maria Odea Ching <[EMAIL PROTECTED]>:
>
> Hi Nicolas,
>
> I'm getting test failures in archiva-proxy after this change, specifically
> in CacheFailuresTransferTest.
> Could you please update the test case to reflect these changes? :)
>
> Thanks,
> Deng
>
>
> On Jan 10, 2008 7:00 PM, <[EMAIL PROTECTED]> wrote:
>
> > Author: nicolas
> > Date: Thu Jan 10 03:00:35 2008
> > New Revision: 610758
> >
> > URL: http://svn.apache.org/viewvc?rev=610758&view=rev
> > Log:
> > skip when URL is in failure cache
> > cache proxy failures (404) for better performances
> >
> > Modified:
> >
>
> >  
> > maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java
> >
> > Modified:
> >
> maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java
> > URL:
> >
> http://svn.apache.org/viewvc/maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java?rev=610758&r1=610757&r2=610758&view=diff
> >
> >
> ==
> > ---
> >
> maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java
> > (original)
> > +++
> >
> maven/archiva/trunk/archiva-base/archiva-proxy/src/main/java/org/apache/maven/archiva/proxy/DefaultRepositoryProxyConnectors.java
> > Thu Jan 10 03:00:35 2008
> > @@ -524,10 +524,15 @@
> > getLogger().info( emsg );
> > return null;
> > }
> > -
> > +
> > +   if ( urlFailureCache.hasFailedBefore( url ) )
> > +   {
> > +   throw new NotFoundException( "Url has failed
> > before and cache-failure is enabled on this connector" );
> > +   }
> > +
> > Wagon wagon = null;
> > try
> > -{
> > +{
> > RepositoryURL repoUrl = remoteRepository.getURL();
> > String protocol = repoUrl.getProtocol();
> > wagon = (Wagon) wagons.get( protocol );
> > @@ -547,7 +552,10 @@
> > }
> > catch ( NotFoundException e )
> > {
> > -// Do not cache url here.
> > +   // public repositories may be slow to access,
> and
> > many request will fail when
> > +   // muliple repositories are "merged" by archiva
> > via proxies.
> > +   // so caching "not found" is usefull here to
> > enhance archiva response-time
> > +urlFailureCache.cacheFailure( url );
> > throw e;
> > }
> > catch ( NotModifiedException e )
> >
> >
> >
>

Re: dependency on archiva-configuration -> archiva-model in r602916 for legacy paths

[nicolas de loof]

I'll look to refactor this next week.

cheers,

Nico.


2007/12/27, Brett Porter <[EMAIL PROTECTED]>:
>
>
> On 28/12/2007, at 5:05 AM, nicolas de loof wrote:
>
> > Just wanted to have LegacyArtifactPath hide the String
> > representation used
> > in storage, but project dependencies is also valuable.
>
> Your reasoning makes sense :)
>
> >
> >
> > Why shouldn't archiva-configuration depend on achiva-model ? IMHO, the
> > "model" should have no dependency. But you can make any change
> > required for
> > better architecture.
>
> That's why I was saying it - configuration is a model also and so I
> was trying to avoid a dependency (note that archiva-model drags in JDO
> among other things - though this is really a problem with archiva-
> model...). I was also trying to avoid code in the configuration class
> where possible - but your reason made sense.
>
> It's not a big deal - just something to think about :)
>
> Cheers,
> Brett
>
>

cache-failure enhancement

[nicolas de loof]

Hello

The cache-failure option on proxy connectors doesn't seem to act as user
(and myself) may expect.

A failing (404) artifact request is not cached, as any network errors.

This has the side effect that :

1. network issues to access proxied repositories can make archiva unusable
2. archiva performance can get slow when using downloadSources form IDE
plugins, as many artifacts have no source attached and any user launching
mvn eclipse:eclipse will make archiva fetch it's proxyConnectors

I suggest the following changes :

- in DefaultRepositoryProxyConnectors, first look in UrlCache for previously
failed request, and skip fetching the proxy if found
- add 404 (ArtifactNotFoundException) errors to the failureCache

The cache is also hard-configured in plexus descriptors. Maybe some user
would like to have an admin command / configuration to flush it and/or the
the time-to-live attribute.

Nico.

Re: [continuum] BUILD FAILURE: Archiva Base :: Configuration

[nicolas de loof]

I noticed your fix on archiva-configuration, thanks.

I now have acces to continuum from my office, without having changed
anything...

2007/12/14, nicolas de loof <[EMAIL PROTECTED]>:
>
> I get 502 Proxy Error when trying to acces continuum, both from Home and
> Office.
> Need something to configure ???
>
> Seems my last update of MDO files to mark version 1.1.0 broke something.
> I'll check this this morning.
>
>
> 2007/12/14, Brett Porter <[EMAIL PROTECTED]>:
> >
> > Nicolas,
> >
> > Did you forget to check something in?
> >
> > - Brett
> >
> > On 14/12/2007, at 12:51 PM, [EMAIL PROTECTED] wrote:
> >
> > > Online report : 
> > > http://maven.zones.apache.org/continuum/buildResult.action?buildId=38858&projectId=271
> >
> > >
> > > Build statistics:
> > > State: Failed
> > > Previous State: Failed
> > > Started at: Fri 14 Dec 2007 01:50:59 +
> > > Finished at: Fri 14 Dec 2007 01:51:17 +
> > > Total time: 17s
> > > Build Trigger: Forced
> > > Build Number: 215
> > > Exit code: 1
> > > Building machine hostname: maven.zones.apache.org
> > > Operating system : SunOS(unknown)
> > > Java Home version :  java version "1.5.0_13"
> > > Java(TM) 2 Runtime Environment, Standard Edition (build
> > > 1.5.0_13-b05)
> > > Java HotSpot(TM) Server VM (build 1.5.0_13-b05 , mixed mode)
> > >Builder version :
> > > Maven version: 2.0.7
> > > Java version: 1.5.0_13
> > > OS name: "sunos" version: "5.10" arch: "x86"
> > >
> > >
> > 
> > > SCM Changes:
> > >
> > 
> > > No files changed
> > >
> > >
> > 
> > > Dependencies Changes:
> > >
> > 
> > > No dependencies changed
> > >
> > >
> > >
> > 
> > > Build Defintion:
> > >
> > 
> > > POM filename: pom.xml
> > > Goals: clean install   Arguments: --batch-mode --non-recursive
> > > Build Fresh: false
> > > Always Build: false
> > > Default Build Definition: true
> > > Schedule: DEFAULT_SCHEDULE
> > > Description:
> > >
> > >
> > 
> > > Test Summary:
> > >
> > 
> > > Tests: 0
> > > Failures: 0
> > > Total time: 0
> > >
> > >
> > 
> > > Output:
> > >
> > 
> >
> > > [INFO] Scanning for projects...
> > > [INFO]
> > >
> > 
> > > [INFO] Building Archiva Base :: Configuration
> > > [INFO]task-segment: [clean, install]
> > > [INFO]
> > >
> > 
> > > [INFO] [clean:clean]
> > > [INFO] Deleting directory /export/home/build/data/continuum/
> > > checkouts/271/target
> > > [INFO] [modello:java {execution: default}]
> > > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > > 271/target/generated-sources/modello
> > > [INFO] Generating current version: 1.0.0
> > > [INFO] [modello:registry-reader {execution: default}]
> > > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > > 271/target/generated-sources/modello
> > > [INFO] Generating current version: 1.0.0
> > > [INFO] [modello:registry-writer {execution: default}]
> > > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > > 271/target/generated-sources/modello
> > > [INFO] Generating current version: 1.0.0
> > > [INFO] [plexus:descriptor {execution: generate}]
> > > [INFO] snapshot org.apache.ma

Re: [continuum] BUILD FAILURE: Archiva Base :: Configuration

[nicolas de loof]

I get 502 Proxy Error when trying to acces continuum, both from Home and
Office.
Need something to configure ???

Seems my last update of MDO files to mark version 1.1.0 broke something.
I'll check this this morning.


2007/12/14, Brett Porter <[EMAIL PROTECTED]>:
>
> Nicolas,
>
> Did you forget to check something in?
>
> - Brett
>
> On 14/12/2007, at 12:51 PM, [EMAIL PROTECTED] wrote:
>
> > Online report :
> http://maven.zones.apache.org/continuum/buildResult.action?buildId=38858&projectId=271
> >
> > Build statistics:
> > State: Failed
> > Previous State: Failed
> > Started at: Fri 14 Dec 2007 01:50:59 +
> > Finished at: Fri 14 Dec 2007 01:51:17 +
> > Total time: 17s
> > Build Trigger: Forced
> > Build Number: 215
> > Exit code: 1
> > Building machine hostname: maven.zones.apache.org
> > Operating system : SunOS(unknown)
> > Java Home version :  java version "1.5.0_13"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > 1.5.0_13-b05)
> > Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode)
> >Builder version :
> > Maven version: 2.0.7
> > Java version: 1.5.0_13
> > OS name: "sunos" version: "5.10" arch: "x86"
> >
> >
> 
> > SCM Changes:
> >
> 
> > No files changed
> >
> >
> 
> > Dependencies Changes:
> >
> 
> > No dependencies changed
> >
> >
> >
> 
> > Build Defintion:
> >
> 
> > POM filename: pom.xml
> > Goals: clean install   Arguments: --batch-mode --non-recursive
> > Build Fresh: false
> > Always Build: false
> > Default Build Definition: true
> > Schedule: DEFAULT_SCHEDULE
> > Description:
> >
> >
> 
> > Test Summary:
> >
> 
> > Tests: 0
> > Failures: 0
> > Total time: 0
> >
> >
> 
> > Output:
> >
> 
> > [INFO] Scanning for projects...
> > [INFO]
> >
> 
> > [INFO] Building Archiva Base :: Configuration
> > [INFO]task-segment: [clean, install]
> > [INFO]
> >
> 
> > [INFO] [clean:clean]
> > [INFO] Deleting directory /export/home/build/data/continuum/
> > checkouts/271/target
> > [INFO] [modello:java {execution: default}]
> > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > 271/target/generated-sources/modello
> > [INFO] Generating current version: 1.0.0
> > [INFO] [modello:registry-reader {execution: default}]
> > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > 271/target/generated-sources/modello
> > [INFO] Generating current version: 1.0.0
> > [INFO] [modello:registry-writer {execution: default}]
> > [INFO] outputDirectory: /export/home/build/data/continuum/checkouts/
> > 271/target/generated-sources/modello
> > [INFO] Generating current version: 1.0.0
> > [INFO] [plexus:descriptor {execution: generate}]
> > [INFO] snapshot org.apache.maven.archiva:archiva-common:1.1-
> > SNAPSHOT: checking for updates from apache.snapshots
> > [INFO] snapshot org.apache.maven.archiva:archiva-policies:1.1-
> > SNAPSHOT: checking for updates from apache.snapshots
> > [INFO] snapshot org.apache.maven.archiva:archiva-model:1.1-SNAPSHOT:
> > checking for updates from apache.snapshots
> > [INFO] Setting property: classpath.resource.loader.class =>
> > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> > [INFO] Setting property: velocimacro.messages.on => 'false'.
> > [INFO] Setting property: resource.loader => 'classpath'.
> > [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> > [INFO] [remote-resources:process {execution: default}]
> > [INFO] [resources:resources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] Copying 2 resources
> > [INFO] Copying 1 resource
> > [INFO] Copying 2 resources
> > [INFO] [compiler:compile]
> > [INFO] Compiling 33 source files to /export/home/build/data/
> > continuum/checkouts/271/target/classes
> > [INFO] [resources:testResources]
> > [INFO] Using default encoding to copy filtered resources.
> > [INFO] Copying 2 resources
> > [INFO] Copying 2 resources
> > [INFO] [compiler:testCompile]
> > [INFO] Compiling 6 source files to /export/home/build/data/continuum/
> > checkouts/271/target/test-classes
> > [I

Re: Network Proxies - use full wagon http instead of lightweight

[nicolas de loof]

Thanks a lot for reporting this issue and how to resole it.

Could you create an entry in Jira and attach a comment or a patch ?

--> http://jira.codehaus.org/browse/MRM
--> http://jira.codehaus.org/browse/PLXCOMP

Nico.

2007/12/2, Julien Lamandé <[EMAIL PROTECTED]>:
>
> Hi to the developement team,
>
> I've tried using Archiva inside an enterprise network. But I got a problem
> to pass through a HTTP proxy with user authentication.
> So I configured a network proxy (a lot of times ;-) ) but no results. The
> proxy configuration seemed to be never used.
>
> Finally, to resolve this problem, I needed to replace the dependency (in
> archiva webapp) "*wagon-http-lightweight-1.0-beta-2*" by the more powerful
> "
> *wagon-http-1.0-beta-2*".
>
> This one makes use of common-http-client that provides full configuration
> of
> network http proxy instead of the "native" environment properties
> http.proxy*
> Now the network connections work gracefully with http proxy with or
> without
> user authentication.
>
> Could you consider replacing those dependencies in archiva, the way I've
> done ?
> I think that I won't be the only one to have the problem.
>
> So I wil go on using the archiva repository. In my team, we were using
> maven-proxy, and were looking for a much advanced one for a while. Thx to
> all.
>
> Julien.
>
>
> P.S. : in the META-INF/plexus/components.xml of the
> wagon-http-lightweight-1.0-beta-2, I think there is an error for the
> "implementation" value of the "role-hint" *https* :
> should be
> *org.apache.maven.wagon.providers.http.LightweightHttpsWagon*
> instead of
> *org.apache.maven.wagon.providers.http.LightweightHttpWagon*
>

MRM-594/595/596

[nicolas de loof]

Just FYI, I deployed a customized archiva instance to replace my corporate
repository. It uses archiva SVN + the patches I provided for MRM-594 595
&596.

All works fine for both m1 and m2 builds on our projects.

On MRM-594 : where could we store custom "legacy path --> artifact"
convertions ? Some new elements in archivaConfiguration ? Use new tables in
archiva DB ?

Nico.

Re: small issue with maven1 (legacy) request resolution

[nicolas de loof]

I just attached a patch to MRM-594

This simply converts PathParsers to plexus components and add support for
some exceptions in the LegacyPathParser path 2 artifact conversion, based on
properties :
path -> groupId:artifactId:version:classifier:type

The resolution of this issue requires some way to manage those properties.
Maybe store them in archiva.xml ? Or in the Database ?

A full user-friendly resolution of this issue will require some web UI
management. I've never used struts2/webwork so can hardly help for this.

Nico.


2007/11/14, nicolas de loof <[EMAIL PROTECTED]>:
>
> Agrea about java-sources, was just for testing.
>
> This is an anoying issue as some maven1 core plugins (plugin-plugin and
> scm-plugin) refer to jaxen-1.0-FCS-full, "full" beeing a classifier in m2
> repo.
>
> I understand you don't want to break for the N'th time the maven1 legacy
> handling.
>
> Could we just consider some "exception-list" in the legacy to Artifact
> discovery ? A property-file based solution would allow archiva admin to
> solve such issues with fiew impacts on archiva.
>
> Nico.
>
>
> 2007/11/13, Joakim Erdfelt <[EMAIL PROTECTED]>:
> >
> > 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<
> > http://sai1rennes:/repository/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<http://sai1rennes:/repository/org/jmonit/jmonit/
> > >>>>> 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: regression in beta-4 : server-side relocation broken

[nicolas de loof]

I just attached a testcase and a patch to solve MRM-595. This requires some
trivial changes on plexus-webdav-api.

Nico.

2007/11/14, nicolas de loof <[EMAIL PROTECTED]>:
>
> Thats right,
>
> I'll first focus on writting such test-cases. This was in my todo list for
> long time :-/
>
> Nico.
>
>
> 2007/11/14, Joakim Erdfelt <[EMAIL PROTECTED]>:
> >
> > 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.
> > >
> > >
> >
> >
>

regression in beta-4 : server-side relocation broken

[nicolas de loof]

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

[nicolas de loof]

Agrea about java-sources, was just for testing.

This is an anoying issue as some maven1 core plugins (plugin-plugin and
scm-plugin) refer to jaxen-1.0-FCS-full, "full" beeing a classifier in m2
repo.

I understand you don't want to break for the N'th time the maven1 legacy
handling.

Could we just consider some "exception-list" in the legacy to Artifact
discovery ? A property-file based solution would allow archiva admin to
solve such issues with fiew impacts on archiva.

Nico.


2007/11/13, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> 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<http://sai1rennes:/repository/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<http://sai1rennes:/repository/org/jmonit/jmonit/
> >>>>> 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

[nicolas de loof]

.. but anyway, would it be usable in a m1 project ?

Having a dependency with a  non-standard type will not be resolved by maven1
to ".jar" extension

2007/11/13, nicolas de loof <[EMAIL PROTECTED]>:
>
> That would be a better description of my issue :
>
> There is no way to access from maven1 some artifacts that use the
> m2-specific "classifier" concept. Using classifier would create
> valid m1 requests but requires to configure some custom type -> extensions
> mappings in archiva.
>
> Nico.
>
> 2007/11/13, Brett Porter <[EMAIL PROTECTED]>:
> >
> > Good point - in fact Joakim had mentioned this already and I gave the
> > same explanation. Coffee helps me remember :)
> >
> > So you're really looking for a feature request to make the m1 type
> > mappings extensible?
> >
> > - Brett
> >
> > On 13/11/2007, at 9:44 AM, 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< http://sai1rennes:/repository/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< http://sai1rennes:/repository/org/jmonit/jmonit/
> > >>>>> 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/
> > >>
> > >>
> >
> > --
> > Brett Porter - [EMAIL PROTECTED]
> > Blog: http://www.devzuz.org/blogs/bporter/
> >
> >
>

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

[nicolas de loof]

+1

2007/11/11, Brett Porter <[EMAIL PROTECTED]>:
>
> +1
>
> On 09/11/2007, at 5:17 AM, 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
>
> --
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>
>

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

[nicolas de loof]

MRM-565 created.

As this makes archiva totaly unusable to maven1 users, I consider this as
blocker, but maven2-only users will never get this issue, and this is only a
beta-release. Based on this "release often" principle wins.

I've no idea how many archiva users use it as maven1 proxy. In my case
archiva is used as a coporate proxy, and maven1 support is required for
legacy projects (and there is many !). The release note should warn on this.

Nico.

2007/10/23, Brett Porter <[EMAIL PROTECTED]>:
>
> *sigh*. Confirmed.
>
> I can see exactly where it is broken too. The resourceExists is using
> what appears to be the request path to look in the managed repository
> which is of a different layout. The error message is also wrong,
> leaving out the repository ID.
>
> I'm going to be bold and say this can wait until beta-4 and should be
> listed as a known issue in the release notes. I'd like to get the
> current release in the hands of the m2 users and progress to beta-4
> early next week. What do others think? Nicolas, in particular, are
> you happy with that or do you feel we should not release it?
>
> Can you make sure this is in JIRA in the mean time?
>
> Cheers,
> Brett
>
> On 23/10/2007, at 6:36 PM, nicolas de loof wrote:
>
> > Sorry to come late on this thread.
> >
> > I made some test as a maven1 client and can't get any content from the
> > repository :
> >
> > http://localhost:8080/archiva/repository/internal/javax/servlet/
> > servlet-api/2.3/servlet-api-2.3.jarreturns
> > the expected jar
> >
> > http://localhost:8080/archiva/repository/internal/javax.servlet/
> > jars/servlet-api-2.3.jar
> > returns 404.
> >
> > Something is broken in this release...
> >
> >
> > Other m1 request that was not resolved in beta2 are now well
> > downloaded, but
> > also fails in 404. It seems ANY legacy request fails.
> >
> > Nico.
> >
> >
> > 2007/10/23, Brett Porter <[EMAIL PROTECTED]>:
> >>
> >>
> >> On 23/10/2007, at 11:06 AM, Joakim Erdfelt wrote:
> >>
> >>>
> >>> 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)
> >>
> >> As detailed in the other mail, not a release blocker, and no
> >> different to the behaviour in the last release.
> >>
> >> - Brett
> >>
> >> --
> >> Brett Porter - [EMAIL PROTECTED]
> >> Blog: http://www.devzuz.org/blogs/bporter/
> >>
>
> --
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>

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

[nicolas de loof]

I tried the same maven1 request on an from-scratch archiva instance running
in plexus (my corporate archiva runs on tomcat5). Same 404 error for legacy
requests.


I also still have the wrapper.conf issue I noticed on beta 2 for windows :

[ERROR] Specified initial heap size (3 MB) is less than the minimum required
initial heap size (8 MB).

changing wrapper.java.initmemory=8 in wrapper.conf solves this.

2007/10/23, nicolas de loof <[EMAIL PROTECTED]>:
>
> Sorry to come late on this thread.
>
> I made some test as a maven1 client and can't get any content from the
> repository :
>
>
> http://localhost:8080/archiva/repository/internal/javax/servlet/servlet-api/2.3/servlet-api-2.3.jarreturns
>  the expected jar
>
>
> http://localhost:8080/archiva/repository/internal/javax.servlet/jars/servlet-api-2.3.jar
> returns 404.
>
> Something is broken in this release...
>
>
> Other m1 request that was not resolved in beta2 are now well downloaded,
> but also fails in 404. It seems ANY legacy request fails.
>
> Nico.
>
>
> 2007/10/23, Brett Porter <[EMAIL PROTECTED]>:
> >
> >
> > On 23/10/2007, at 11:06 AM, Joakim Erdfelt wrote:
> >
> > >
> > > 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)
> >
> > As detailed in the other mail, not a release blocker, and no
> > different to the behaviour in the last release.
> >
> > - Brett
> >
> > --
> > Brett Porter - [EMAIL PROTECTED]
> > Blog: http://www.devzuz.org/blogs/bporter/
> >
>
>

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

[nicolas de loof]

Sorry to come late on this thread.

I made some test as a maven1 client and can't get any content from the
repository :

http://localhost:8080/archiva/repository/internal/javax/servlet/servlet-api/2.3/servlet-api-2.3.jarreturns
the expected jar

http://localhost:8080/archiva/repository/internal/javax.servlet/jars/servlet-api-2.3.jar
returns 404.

Something is broken in this release...


Other m1 request that was not resolved in beta2 are now well downloaded, but
also fails in 404. It seems ANY legacy request fails.

Nico.


2007/10/23, Brett Porter <[EMAIL PROTECTED]>:
>
>
> On 23/10/2007, at 11:06 AM, Joakim Erdfelt wrote:
>
> >
> > 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)
>
> As detailed in the other mail, not a release blocker, and no
> different to the behaviour in the last release.
>
> - Brett
>
> --
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/
>

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

[nicolas de loof]

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

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

[nicolas de loof]

Let's take a simple example, that breaks in the current archiva beta :

Archiva is configured to use a default-layout managed repo and proxies
central (default configuration)

-  maven1 client requests "maven/plugins/maven-test-plugin-1.9.jar"

Archiva must convert the incoming request to ArtifactReference, to check for
file in the maven repo or fetch the proxies.
The requestes "maven-test-plugin-1.9" must be splitted into [ artifactId :
version : classifier ]
We have no other information on the incoming request.

option 1 :
Joakim suggested to get those datas from the POM. This cannot apply here as
we cannot create the PomReference for the same reason we cannot create the
ArtifactReference.

Joakim also proposed to rework the archiva design and move the
arifactReference resolution to be less central. This would make easier to
plug some resolution strategy from the web UI.

option 2 :
I suggested to use the current regex-based splitter and to check for the
expected file to exist. If not, then the regex may be wrong, then build all
possible [ artifactId : version : classifier ] and check for the file to
exist... (the result of this discovery should be cached somewhere to avoid
network cost).

The issue with the current design is that this artifactId:version:classifier
resolution is done in some util classes that have no acces to the
repository/proxies. The only way to solve this would be to pass an
ArtifactReferenceVerifier as parameter that check the file to exist, but
this may have impact on other archiva components, consumers for example.

I agree with Joakim that the current design is broken, as the
BidirectionLayout interface makes assumption that path to ArtifactReference
is deterministic, and legacy layout is not. So the API must be changed in
any way to reflect this limitation.

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

Nico.


2007/10/9, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> 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 a

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

[nicolas de loof]

So, from any incoming request we can set what layout to apply based on
number of "/".

For default layouts, all required info are well splited in the path.
For legacy one, your proposal of loading the POM to read artifactId is
broken :

- if the managed/proxied repository also uses a legacy layout (so that
replacing extension with "pom" gets the pom, we must anyway remove any
classifier (jaxen-1.0-FCS-full.jar for example -> faxen-1.0-FCS.pom)... and
the POM must exists !.

- if the target (proxied) repository use default layout, we need the
artifactId + version (+classifier) to get the pom path to request

So in both cases we cannot get the POM prior to knowing the artifactId :
version : classifier from the incoming request.


Your idea of moving this problem to the web layer, and avoinding
BidirectionalLayouts from beeing so central is interesting. I don't know
enought about impacts on consumers and other archiva components to give an
opinion. I just tried to refactor this interface and got so much changes...

If the new RepositoryContent interface works in front of a repository
(including proxies connectors), it can check for artifacts/pom to exist, so
it can build the list of all possible artifactId:version:classifier from an
incoming legacy request, and search for the artifact to exist - and then
find the expected one - before returning the ArtifactReference. The current
RepositoryLayoutUtils / VersionUtils could be used to avoid to much network
traffic, as it solves many artifactIds/version well.

Nico.

2007/10/6, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> 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 Referen

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

[nicolas de loof]

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" 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.
>
> The problem with this approach is maintaining the list of extensions to
> artifact type.  The artifact type is arbitrary, and can be expanded
> upon by the user to include types th

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

[nicolas de loof]

I've attached a patch to MRM-517 : it adds an optional proposedVersion
parameter to splitFilename (method with 2 params is keeped for
compatibility)

I also added a testcase based on the Jira example.

2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
> I investigate the MRM-517 issue :
> "/org/hibernate/jtidy/r8-21122004/jtidy-r8-21122004.jar"
>
> The DefaultBidirectionalRepositoryLayoutrecognizes the request to be a
> well formed m2, but it fails on sanity cheks (line 255) :
>
> // Sanity Checks.
> if ( prefs.fileParts != null )
> {
> /* Compare artifact version to path baseversion.
>  *
>  * Version naming in the wild can be strange at times.
>  * Sometimes what is seen as a classifier is actually part
> of the version id.
>  *
>  * To compensate for this, the path is checked against the
> artifact.version and
>  *  the concatenation of the artifact.version + "-" +
> artifact.classifier
>  */
> ...
>
> The version part found by RepositoryLayoutUtils.splitFilename() does
> not include the "r8" in the version, as it is not a valid
> versionKeyword.
>
> Same for the fop example : "trunk" is not a valid versionKeyword
>
> Just two questions :
>
> - is this sanity check really usefull to parse a m2 request path ?
> - if so, should we
>   - improve RepositoryLayoutUtils.splitFileName to get an optional
> possibleVersion argument ?
>   - apply the strategy of multiple artifactId/version for 1 request ?
>
> Nico.
>
> The path is recognized as beeign a well formed m2 request, but the
> toPathReferences throws an exception as it doesn't recognize the
> version used in the filename : RepositoryLayoutUtils.splitFilename
> does not recognize "r8" as a valid versionKeyword.
>
> 2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
> > > 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.
> >
> > 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.
> >
>

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

[nicolas de loof]

I investigate the MRM-517 issue :
"/org/hibernate/jtidy/r8-21122004/jtidy-r8-21122004.jar"

The DefaultBidirectionalRepositoryLayoutrecognizes the request to be a
well formed m2, but it fails on sanity cheks (line 255) :

// Sanity Checks.
if ( prefs.fileParts != null )
{
/* Compare artifact version to path baseversion.
 *
 * Version naming in the wild can be strange at times.
 * Sometimes what is seen as a classifier is actually part
of the version id.
 *
 * To compensate for this, the path is checked against the
artifact.version and
 *  the concatenation of the artifact.version + "-" +
artifact.classifier
 */
...

The version part found by RepositoryLayoutUtils.splitFilename() does
not include the "r8" in the version, as it is not a valid
versionKeyword.

Same for the fop example : "trunk" is not a valid versionKeyword

Just two questions :

- is this sanity check really usefull to parse a m2 request path ?
- if so, should we
  - improve RepositoryLayoutUtils.splitFileName to get an optional
possibleVersion argument ?
  - apply the strategy of multiple artifactId/version for 1 request ?

Nico.

The path is recognized as beeign a well formed m2 request, but the
toPathReferences throws an exception as it doesn't recognize the
version used in the filename : RepositoryLayoutUtils.splitFilename
does not recognize "r8" as a valid versionKeyword.

2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
> > 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.
>
> 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.
>

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

[nicolas de loof]

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

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.

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

[nicolas de loof]

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

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

[nicolas de loof]

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
>

critical issue with 1.0-beta-2 !!!

[nicolas de loof]

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

Re: Archiva 1.0-beta-2 Release Schedule

[nicolas de loof]

Thnaks for applying ;-p
My local archiva will be in sync with SVN for the first time since
early pre-0.9 snapshots !

2007/9/16, Maria Odea Ching <[EMAIL PROTECTED]>:
> Patch applied for MRM-153..
> Thanks Nicolas!
>
> -Deng
>
> Arnaud HERITIER wrote:
> > Perfect Nicolas
> > Thx a lot for your help !!
> >
> > On 14/09/2007, nicolas de loof <[EMAIL PROTECTED]> wrote:
> >
> >> Not sure about this, but MRM-308 seems to be resolved in SVN :
> >>
> >> my managed repo uses default layout and I can get both :
> >>
> >> http://localhost:8080/archiva/repository/internal/ant/jars/ant-1.6.5.jar
> >> and
> >>
> >> http://localhost:8080/archiva/repository/internal//ant/ant/1.6.5/ant-1.6.5.jar
> >>
> >> MRM-211 is still blocking to use archiva with maven1. It only requires
> >> an entry in components.xml to be solved !
> >>
> >> Nico.
> >>
> >> 2007/9/14, nicolas de loof <[EMAIL PROTECTED]>:
> >>
> >>> I just attached my patch (MRM153-1.0-beta-2.patch).
> >>> -> http://jira.codehaus.org/browse/MRM-153
> >>>
> >>> I tested it on my corporate archiva instance to get servlet-api-2.3
> >>> using various paths :
> >>>
> >>> maven2 (javax/servlet/servlet-api/2.3/servlet-api-2.3.jar)
> >>> maven2 with "client-side" relocation (servletapi/2.3/servletapi-2.3.pom)
> >>>
> >>> maven1 (javax.servlet/jars/servlet-api-2.3.jar)
> >>> maven1 with "server-side" relocation (servletapi/2.3/servletapi-2.3.jar)
> >>>
> >>> I need help to write some integration test to document/instrument this
> >>> feature, as I'm not familiar with both plexus and servlets automated
> >>> testing.
> >>>
> >>> Nico
> >>>
> >>>
> >>> 2007/9/13, Brett Porter <[EMAIL PROTECTED]>:
> >>>
> >>>> Thanks!
> >>>>
> >>>> On 14/09/2007, at 12:34 AM, nicolas de loof wrote:
> >>>>
> >>>>
> >>>>> I have lot's of maven1 project on my side.
> >>>>> I'll attach an updated patch as soon as possible for MRM-153.
> >>>>>
> >>>>> Nico.
> >>>>>
> >>>>> 2007/9/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> >>>>>
> >>>>>> I have less and less m1 projects around me ;-)
> >>>>>> When I find one, I move it to m2 ;-)
> >>>>>>
> >>>>>> Arnaud
> >>>>>>
> >>>>>> On 13/09/2007, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> I agree. Actually, a couple of these already have patches. I was
> >>>>>>> going to run through and apply them but if you're actively using
> >>>>>>>
> >> the
> >>
> >>>>>>> maven1 stuff and can test it better then by all means assign them
> >>>>>>>
> >> to
> >>
> >>>>>>> yourself and put them in if they work :)
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Brett
> >>>>>>>
> >>>>>>> On 13/09/2007, at 8:10 PM, Arnaud HERITIER wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> I hope that maven 1 issues [MRM-153, MRM-211, MRM-308] will be
> >>>>>>>> fixed in the
> >>>>>>>> next beta. when it worked it was very useful to help companies to
> >>>>>>>> migrate
> >>>>>>>> maven 1 projects to maven 2.
> >>>>>>>>
> >>>>>>>> The problem in MRM-243 isn't in archiva itself but it prevents to
> >>>>>>>> deploy
> >>>>>>>> artifact from a CI server if archiva is on windows (it creates
> >>>>>>>>
> >> too
> >>
> >>>>>>>> many
> >>>>>>>> build failures).
> >>>>>>>>
> >>>>>>>> MRM-385 has to be fixed before the release !
> >>>>>>>>
> >>>>>>>> Arnaud
> >>>>>>>>
> >>>>>>>> On 13/09/2007, Maria Odea Ching &l

Re: Archiva 1.0-beta-2 Release Schedule

[nicolas de loof]

Not sure about this, but MRM-308 seems to be resolved in SVN :

my managed repo uses default layout and I can get both :
   http://localhost:8080/archiva/repository/internal/ant/jars/ant-1.6.5.jar
and
   
http://localhost:8080/archiva/repository/internal//ant/ant/1.6.5/ant-1.6.5.jar

MRM-211 is still blocking to use archiva with maven1. It only requires
an entry in components.xml to be solved !

Nico.

2007/9/14, nicolas de loof <[EMAIL PROTECTED]>:
> I just attached my patch (MRM153-1.0-beta-2.patch).
> -> http://jira.codehaus.org/browse/MRM-153
>
> I tested it on my corporate archiva instance to get servlet-api-2.3
> using various paths :
>
> maven2 (javax/servlet/servlet-api/2.3/servlet-api-2.3.jar)
> maven2 with "client-side" relocation (servletapi/2.3/servletapi-2.3.pom)
>
> maven1 (javax.servlet/jars/servlet-api-2.3.jar)
> maven1 with "server-side" relocation (servletapi/2.3/servletapi-2.3.jar)
>
> I need help to write some integration test to document/instrument this
> feature, as I'm not familiar with both plexus and servlets automated
> testing.
>
> Nico
>
>
> 2007/9/13, Brett Porter <[EMAIL PROTECTED]>:
> > Thanks!
> >
> > On 14/09/2007, at 12:34 AM, nicolas de loof wrote:
> >
> > > I have lot's of maven1 project on my side.
> > > I'll attach an updated patch as soon as possible for MRM-153.
> > >
> > > Nico.
> > >
> > > 2007/9/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> > >> I have less and less m1 projects around me ;-)
> > >> When I find one, I move it to m2 ;-)
> > >>
> > >> Arnaud
> > >>
> > >> On 13/09/2007, Brett Porter <[EMAIL PROTECTED]> wrote:
> > >>>
> > >>> I agree. Actually, a couple of these already have patches. I was
> > >>> going to run through and apply them but if you're actively using the
> > >>> maven1 stuff and can test it better then by all means assign them to
> > >>> yourself and put them in if they work :)
> > >>>
> > >>> Cheers,
> > >>> Brett
> > >>>
> > >>> On 13/09/2007, at 8:10 PM, Arnaud HERITIER wrote:
> > >>>
> > >>>> I hope that maven 1 issues [MRM-153, MRM-211, MRM-308] will be
> > >>>> fixed in the
> > >>>> next beta. when it worked it was very useful to help companies to
> > >>>> migrate
> > >>>> maven 1 projects to maven 2.
> > >>>>
> > >>>> The problem in MRM-243 isn't in archiva itself but it prevents to
> > >>>> deploy
> > >>>> artifact from a CI server if archiva is on windows (it creates too
> > >>>> many
> > >>>> build failures).
> > >>>>
> > >>>> MRM-385 has to be fixed before the release !
> > >>>>
> > >>>> Arnaud
> > >>>>
> > >>>> On 13/09/2007, Maria Odea Ching <[EMAIL PROTECTED]> wrote:
> > >>>>>
> > >>>>> Hi Everyone,
> > >>>>>
> > >>>>> I will prepare the release of Archiva 1.0-beta-2 on Sept. 15
> > >>>>> (Saturday,
> > >>>>> my time). :-)
> > >>>>>
> > >>>>> Below are the jira issues scheduled for this release, some of
> > >>>>> which will
> > >>>>> probably be moved to
> > >>>>> the next beta release if it won't make it on Saturday.
> > >>>>>
> > >>>>>
> > >>>>> 1. Closed/Resolved:
> > >>>>>
> > >>>>> * [MRM-144] - fix miscellaneous tasks listed in important TODO
> > >>>>> items
> > >>>>> * [MRM-374] - Changes aren't saved when updating Archiva Managed
> > >>>>> Snapshot Repository
> > >>>>> * [MRM-383] - Unable to add new file types for Repository Scanning
> > >>>>> * [MRM-392] - pressing 'return' in the blacklist/whitelist form
> > >>>>> field
> > >>>>> submits whole form and validates, not pressing associated button
> > >>>>> * [MRM-393] - Can't delete blacklist/whitelist pattern
> > >>>>> * [MRM-407] - "Scanned" is always set to true even if unchecked in
> > >>>>> the
> > >>>>> Edit Repository page
>

Re: Archiva 1.0-beta-2 Release Schedule

[nicolas de loof]

I just attached my patch (MRM153-1.0-beta-2.patch).
-> http://jira.codehaus.org/browse/MRM-153

I tested it on my corporate archiva instance to get servlet-api-2.3
using various paths :

maven2 (javax/servlet/servlet-api/2.3/servlet-api-2.3.jar)
maven2 with "client-side" relocation (servletapi/2.3/servletapi-2.3.pom)

maven1 (javax.servlet/jars/servlet-api-2.3.jar)
maven1 with "server-side" relocation (servletapi/2.3/servletapi-2.3.jar)

I need help to write some integration test to document/instrument this
feature, as I'm not familiar with both plexus and servlets automated
testing.

Nico


2007/9/13, Brett Porter <[EMAIL PROTECTED]>:
> Thanks!
>
> On 14/09/2007, at 12:34 AM, nicolas de loof wrote:
>
> > I have lot's of maven1 project on my side.
> > I'll attach an updated patch as soon as possible for MRM-153.
> >
> > Nico.
> >
> > 2007/9/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> >> I have less and less m1 projects around me ;-)
> >> When I find one, I move it to m2 ;-)
> >>
> >> Arnaud
> >>
> >> On 13/09/2007, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>>
> >>> I agree. Actually, a couple of these already have patches. I was
> >>> going to run through and apply them but if you're actively using the
> >>> maven1 stuff and can test it better then by all means assign them to
> >>> yourself and put them in if they work :)
> >>>
> >>> Cheers,
> >>> Brett
> >>>
> >>> On 13/09/2007, at 8:10 PM, Arnaud HERITIER wrote:
> >>>
> >>>> I hope that maven 1 issues [MRM-153, MRM-211, MRM-308] will be
> >>>> fixed in the
> >>>> next beta. when it worked it was very useful to help companies to
> >>>> migrate
> >>>> maven 1 projects to maven 2.
> >>>>
> >>>> The problem in MRM-243 isn't in archiva itself but it prevents to
> >>>> deploy
> >>>> artifact from a CI server if archiva is on windows (it creates too
> >>>> many
> >>>> build failures).
> >>>>
> >>>> MRM-385 has to be fixed before the release !
> >>>>
> >>>> Arnaud
> >>>>
> >>>> On 13/09/2007, Maria Odea Ching <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>> Hi Everyone,
> >>>>>
> >>>>> I will prepare the release of Archiva 1.0-beta-2 on Sept. 15
> >>>>> (Saturday,
> >>>>> my time). :-)
> >>>>>
> >>>>> Below are the jira issues scheduled for this release, some of
> >>>>> which will
> >>>>> probably be moved to
> >>>>> the next beta release if it won't make it on Saturday.
> >>>>>
> >>>>>
> >>>>> 1. Closed/Resolved:
> >>>>>
> >>>>> * [MRM-144] - fix miscellaneous tasks listed in important TODO
> >>>>> items
> >>>>> * [MRM-374] - Changes aren't saved when updating Archiva Managed
> >>>>> Snapshot Repository
> >>>>> * [MRM-383] - Unable to add new file types for Repository Scanning
> >>>>> * [MRM-392] - pressing 'return' in the blacklist/whitelist form
> >>>>> field
> >>>>> submits whole form and validates, not pressing associated button
> >>>>> * [MRM-393] - Can't delete blacklist/whitelist pattern
> >>>>> * [MRM-407] - "Scanned" is always set to true even if unchecked in
> >>>>> the
> >>>>> Edit Repository page
> >>>>> * [MRM-408] - The mvn deploy:deploy-file command gives "Parent
> >>>>> doesn't
> >>>>> exist" in a fresh install
> >>>>> * [MRM-409] - No checking of invalid poms or artifacts during
> >>>>> repository
> >>>>> scanning resulting to some objects not being found on the database
> >>>>> * [MRM-436] - incorrect default cron expression for snapshots
> >>>>> repository
> >>>>> * [MRM-438] - broken images in the download box on the artifact
> >>>>> page
> >>>>> * [MRM-441] - removing a "remote repository" should not present
> >>>>> the page
> >>>>> about handling content
> >>>>> * [MRM-449] - improvement to the reports form 

Re: Archiva 1.0-beta-2 Release Schedule

[nicolas de loof]

I have lot's of maven1 project on my side.
I'll attach an updated patch as soon as possible for MRM-153.

Nico.

2007/9/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> I have less and less m1 projects around me ;-)
> When I find one, I move it to m2 ;-)
>
> Arnaud
>
> On 13/09/2007, Brett Porter <[EMAIL PROTECTED]> wrote:
> >
> > I agree. Actually, a couple of these already have patches. I was
> > going to run through and apply them but if you're actively using the
> > maven1 stuff and can test it better then by all means assign them to
> > yourself and put them in if they work :)
> >
> > Cheers,
> > Brett
> >
> > On 13/09/2007, at 8:10 PM, Arnaud HERITIER wrote:
> >
> > > I hope that maven 1 issues [MRM-153, MRM-211, MRM-308] will be
> > > fixed in the
> > > next beta. when it worked it was very useful to help companies to
> > > migrate
> > > maven 1 projects to maven 2.
> > >
> > > The problem in MRM-243 isn't in archiva itself but it prevents to
> > > deploy
> > > artifact from a CI server if archiva is on windows (it creates too
> > > many
> > > build failures).
> > >
> > > MRM-385 has to be fixed before the release !
> > >
> > > Arnaud
> > >
> > > On 13/09/2007, Maria Odea Ching <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Hi Everyone,
> > >>
> > >> I will prepare the release of Archiva 1.0-beta-2 on Sept. 15
> > >> (Saturday,
> > >> my time). :-)
> > >>
> > >> Below are the jira issues scheduled for this release, some of
> > >> which will
> > >> probably be moved to
> > >> the next beta release if it won't make it on Saturday.
> > >>
> > >>
> > >> 1. Closed/Resolved:
> > >>
> > >> * [MRM-144] - fix miscellaneous tasks listed in important TODO items
> > >> * [MRM-374] - Changes aren't saved when updating Archiva Managed
> > >> Snapshot Repository
> > >> * [MRM-383] - Unable to add new file types for Repository Scanning
> > >> * [MRM-392] - pressing 'return' in the blacklist/whitelist form field
> > >> submits whole form and validates, not pressing associated button
> > >> * [MRM-393] - Can't delete blacklist/whitelist pattern
> > >> * [MRM-407] - "Scanned" is always set to true even if unchecked in
> > >> the
> > >> Edit Repository page
> > >> * [MRM-408] - The mvn deploy:deploy-file command gives "Parent
> > >> doesn't
> > >> exist" in a fresh install
> > >> * [MRM-409] - No checking of invalid poms or artifacts during
> > >> repository
> > >> scanning resulting to some objects not being found on the database
> > >> * [MRM-436] - incorrect default cron expression for snapshots
> > >> repository
> > >> * [MRM-438] - broken images in the download box on the artifact page
> > >> * [MRM-441] - removing a "remote repository" should not present
> > >> the page
> > >> about handling content
> > >> * [MRM-449] - improvement to the reports form group search
> > >> * [MRM-450] - change default label for repository ID report search to
> > >> "All repositories" instead of ""
> > >> * [MRM-453] - Create missing tests for repository purge
> > >> * [MRM-456] - current configuration code is too likely to complain
> > >> about
> > >> multiple sources
> > >> * [MRM-457] - don't display the snapshot removal options in the
> > >> repository list page if snapshots are not included
> > >> * [MRM-462] - separate configuration of managed repositories from
> > >> remote
> > >> repositories
> > >> * [MRM-463] - Metadata merging doesn't work.
> > >> * [MRM-465] - [Load Testing] When asking for pages that require the
> > >> effective-pom in high load, app becomes unresponsive.
> > >> * [MRM-467] - 500 error when user requested the dependency tree for
> > >> artifact
> > >> * [MRM-471] - Create a sample project that demonstrates how a
> > >> component
> > >> can be plugged into Archiva.
> > >> * [MRM-472] - Re-enabled metadata tests in archiva-proxy
> > >> * [MRM-473] - Fix the proxy code (and possibly the tests) to ensure
> > >> proper merging of metadata.xml files.
> > >> * [MRM-474] - Create tests for non-snapshot metadata merging
> > >> * [MRM-475] - Create tests for snapshot metadata merging
> > >> * [MRM-496] - adding a proxy connector action is not working after
> > >> repository changes
> > >>
> > >>
> > >> 2. Open/In-Progress:
> > >>
> > >> * [MRM-128] - better handling of jar artifacts without a pom
> > >> * [MRM-130] - improve search results page
> > >> * [MRM-153] - when used as a maven1 proxy, Archiva should handle
> > >> relocation from maven2 poms
> > >> * [MRM-196] - paginate results
> > >> * [MRM-203] - Reports should be public, not an administration feature
> > >> * [MRM-211] - Cannot use Archiva to get Maven1 Plugins
> > >> * [MRM-243] - 507 Insufficient Storage when deploying artifact
> > >> with webdav
> > >> * [MRM-308] - Maven1 requests are not served
> > >> * [MRM-309] - relocated artifacts are not delivered
> > >> * [MRM-320] - ProxiedDavServer breaks update policy
> > >> * [MRM-385] - Maven config docs refer to /proxy urls
> > >> * [MRM-398] - configure guest access by default for pre-configured
> > >> repositor

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

[nicolas de loof]

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

2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
>
> Without those configuration issues, you get my +1 for a beta.
>
> the "repository/*" url works fine for both maven1 and maven2 requests.
> The only feature I'm still missing is having archiva internally  handling
> relocation for artifacts requested by maven1... maybe in beta-3 ?
>
> I also notice the ProxiedDavServer "get" method still use hasResource()
> and bypass fetching from propxies if present, so there's no way to get newer
> snapshots. This may change with the separation between webdav and "GET"
> urls.
>
> Nico.
>
>
>
> 2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
> >
> > MRM-460 created.
> > The typo is only in CacheFailurePolicy log message.
> > The main issue is about the archiva default config that refers to an
> > invalid "cache" value.
> >
> >
> > Abnother issue with the proposed beta : I had to edit wrapper.conf to
> > set
> >wrapper.java.initmemory=8
> > as I got (on windows, using run.bat) :
> > jvm 1| [ERROR] Specified initial heap size (3 MB) is less than the
> > minimum required initial heap size (8 MB).
> > jvm 1| Could not create the Java virtual machine.
> >
> >
> > 2007/8/7, Brett Porter <[EMAIL PROTECTED]>:
> > >
> > > Is this actually the checksum policy checker, or is it a typo in the
> > > description too?
> > >
> > > Can you put this as a patch in jira? :)
> > >
> > > - Brett
> > >
> > > On 07/08/2007, at 6:55 PM, nicolas de loof wrote:
> > >
> > > > It seems to be a typo in CachedFailuresPolicy
> > > >
> > > > "
> > > > public boolean applyPolicy( String policySetting, Properties
> > > > request,
> > > > File localFile )
> > > > {
> > > > if ( !options.contains( policySetting ) )
> > > > {
> > > > // No valid code? false it is then.
> > > > getLogger().error( "Unknown checksum policyCode [" +
> > > > policySetting + "]" );
> > > > return false;
> > > > }
> > > > "
> > > >
> > > > That beeing said, the constant is set to "cached" and the default
> > > > config to
> > > > "cache".
> > > > Editing the network-proxies and setting to "cached" solved this.
> > > >
> > > >
> > > > 2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
> > > >>
> > > >> I cannot get any artifact from proxy due to some strange checksum
> > > >> policy
> > > >> error :
> > > >>
> > > >> According to log, the proxied-repo is set to policy[checksum]:fix :
> > > >> ProxyConnector[
> > > >> jvm 1|
> > > >> source:ArchivaRepository[internal,file://D:\temp\.data/
> > > >> repositories/internal]
> > > >> jvm 1|   target:ArchivaRepository[central,
> > > >> http://repo1.maven.org/maven2]
> > > >> jvm 1|   proxyId:
> > > >> jvm 1|   policy[releases]:once
> > > >> jvm 1|   policy[checksum]:fix
> > > >> jvm 1|   policy[snapshots]:disabled
> > > >> jvm 1|   policy[cache-failures]:cache
> > > >> jvm 1| ]
> > > >>
> > > >> But latter, I get an Error about Unknown checksum policyCode
> > > [cache]
> > > >>
> > > >> jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
> > > >> org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures  -
> > > >> Unknown checksum policyCode
> > > >>
> > > >>
> > > >> I also had to delete my old $HOME/.m2/archiva.xml as I cannot make
> > > >> any
> > > >> change in the configuration "cannot save configuration when 2
> > > >> sources are
> > > >> used".
> > > >> Is there any update guide to convert old-style configuration into
> > > >> archiva
> > > >> 1.0 ? If none, why does archiva still read this deprecated and
> > > >> uneditable
> > > >> archiva.xml file ?
> > > >>
> > > >> Nico.
> > > >>
> > >
> >
> >
>

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

[nicolas de loof]

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

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

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

Nico.



2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
>
> MRM-460 created.
> The typo is only in CacheFailurePolicy log message.
> The main issue is about the archiva default config that refers to an
> invalid "cache" value.
>
>
> Abnother issue with the proposed beta : I had to edit wrapper.conf to set
>wrapper.java.initmemory=8
> as I got (on windows, using run.bat) :
> jvm 1| [ERROR] Specified initial heap size (3 MB) is less than the
> minimum required initial heap size (8 MB).
> jvm 1| Could not create the Java virtual machine.
>
>
> 2007/8/7, Brett Porter <[EMAIL PROTECTED]>:
> >
> > Is this actually the checksum policy checker, or is it a typo in the
> > description too?
> >
> > Can you put this as a patch in jira? :)
> >
> > - Brett
> >
> > On 07/08/2007, at 6:55 PM, nicolas de loof wrote:
> >
> > > It seems to be a typo in CachedFailuresPolicy
> > >
> > > "
> > > public boolean applyPolicy( String policySetting, Properties
> > > request,
> > > File localFile )
> > > {
> > > if ( !options.contains( policySetting ) )
> > > {
> > > // No valid code? false it is then.
> > > getLogger().error( "Unknown checksum policyCode [" +
> > > policySetting + "]" );
> > > return false;
> > > }
> > > "
> > >
> > > That beeing said, the constant is set to "cached" and the default
> > > config to
> > > "cache".
> > > Editing the network-proxies and setting to "cached" solved this.
> > >
> > >
> > > 2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
> > >>
> > >> I cannot get any artifact from proxy due to some strange checksum
> > >> policy
> > >> error :
> > >>
> > >> According to log, the proxied-repo is set to policy[checksum]:fix :
> > >> ProxyConnector[
> > >> jvm 1|
> > >> source:ArchivaRepository[internal,file://D:\temp\.data/
> > >> repositories/internal]
> > >> jvm 1|   target:ArchivaRepository[central,
> > >> http://repo1.maven.org/maven2]
> > >> jvm 1|   proxyId:
> > >> jvm 1|   policy[releases]:once
> > >> jvm 1|   policy[checksum]:fix
> > >> jvm 1|   policy[snapshots]:disabled
> > >> jvm 1|   policy[cache-failures]:cache
> > >> jvm 1| ]
> > >>
> > >> But latter, I get an Error about Unknown checksum policyCode [cache]
> > >>
> > >> jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
> > >> org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures  -
> > >> Unknown checksum policyCode
> > >>
> > >>
> > >> I also had to delete my old $HOME/.m2/archiva.xml as I cannot make
> > >> any
> > >> change in the configuration "cannot save configuration when 2
> > >> sources are
> > >> used".
> > >> Is there any update guide to convert old-style configuration into
> > >> archiva
> > >> 1.0 ? If none, why does archiva still read this deprecated and
> > >> uneditable
> > >> archiva.xml file ?
> > >>
> > >> Nico.
> > >>
> >
>
>

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

[nicolas de loof]

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


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


2007/8/7, Brett Porter <[EMAIL PROTECTED]>:
>
> Is this actually the checksum policy checker, or is it a typo in the
> description too?
>
> Can you put this as a patch in jira? :)
>
> - Brett
>
> On 07/08/2007, at 6:55 PM, nicolas de loof wrote:
>
> > It seems to be a typo in CachedFailuresPolicy
> >
> > "
> > public boolean applyPolicy( String policySetting, Properties
> > request,
> > File localFile )
> > {
> > if ( !options.contains( policySetting ) )
> > {
> > // No valid code? false it is then.
> > getLogger().error( "Unknown checksum policyCode [" +
> > policySetting + "]" );
> > return false;
> > }
> > "
> >
> > That beeing said, the constant is set to "cached" and the default
> > config to
> > "cache".
> > Editing the network-proxies and setting to "cached" solved this.
> >
> >
> > 2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
> >>
> >> I cannot get any artifact from proxy due to some strange checksum
> >> policy
> >> error :
> >>
> >> According to log, the proxied-repo is set to policy[checksum]:fix :
> >> ProxyConnector[
> >> jvm 1|
> >> source:ArchivaRepository[internal,file://D:\temp\.data/
> >> repositories/internal]
> >> jvm 1|   target:ArchivaRepository[central,
> >> http://repo1.maven.org/maven2]
> >> jvm 1|   proxyId:
> >> jvm 1|   policy[releases]:once
> >> jvm 1|   policy[checksum]:fix
> >> jvm 1|   policy[snapshots]:disabled
> >> jvm 1|   policy[cache-failures]:cache
> >> jvm 1| ]
> >>
> >> But latter, I get an Error about Unknown checksum policyCode [cache]
> >>
> >> jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
> >> org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures  -
> >> Unknown checksum policyCode
> >>
> >>
> >> I also had to delete my old $HOME/.m2/archiva.xml as I cannot make
> >> any
> >> change in the configuration "cannot save configuration when 2
> >> sources are
> >> used".
> >> Is there any update guide to convert old-style configuration into
> >> archiva
> >> 1.0 ? If none, why does archiva still read this deprecated and
> >> uneditable
> >> archiva.xml file ?
> >>
> >> Nico.
> >>
>

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

[nicolas de loof]

It seems to be a typo in CachedFailuresPolicy

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

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


2007/8/7, nicolas de loof <[EMAIL PROTECTED]>:
>
> I cannot get any artifact from proxy due to some strange checksum policy
> error :
>
> According to log, the proxied-repo is set to policy[checksum]:fix :
> ProxyConnector[
> jvm 1|
> source:ArchivaRepository[internal,file://D:\temp\.data/repositories/internal]
> jvm 1|   target:ArchivaRepository[central,
> http://repo1.maven.org/maven2]
> jvm 1|   proxyId:
> jvm 1|   policy[releases]:once
> jvm 1|   policy[checksum]:fix
> jvm 1|   policy[snapshots]:disabled
> jvm 1|   policy[cache-failures]:cache
> jvm 1| ]
>
> But latter, I get an Error about Unknown checksum policyCode [cache]
>
> jvm 1| 2007-08-07 10:37:20,481 [SocketListener0-1] ERROR
> org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures  -
> Unknown checksum policyCode
>
>
> I also had to delete my old $HOME/.m2/archiva.xml as I cannot make any
> change in the configuration "cannot save configuration when 2 sources are
> used".
> Is there any update guide to convert old-style configuration into archiva
> 1.0 ? If none, why does archiva still read this deprecated and uneditable
> archiva.xml file ?
>
> Nico.
>

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

[nicolas de loof]

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

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

But latter, I get an Error about Unknown checksum policyCode [cache]

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


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

Nico.

Re: What is Archiva.NEXT ?

[nicolas de loof]

>
>
> Maven 2, Maven 1.1, and Ivy work right now.   They all support the maven
> 2 default layout fine.
>

Does maven 1.1 really support maven2 layout for remote repository (and local
?) !!
How do you configure it for this ?

Re: What is Archiva.NEXT ?

[nicolas de loof]

"one such collision in naming is when a metadata.xml file is requested and
the path is detected as a
maven 1 resource"

Just surpised about this : would any maven 1.x client request for meta-datas
? AFAIK maven1 only request for artifacts (jars) and never for POMs or
meta-data.xml ?

just my 2 cents...

2007/7/31, Joakim Erdfelt <[EMAIL PROTECTED]>:
>
> I'm tired.
> I'm tired of the confusion.
> I'm tired of the lack of decision.
>
> The ability to serve the repository information to multiple clients is
> exactly the reason for splitting this logic out.
>
> It's nearly impossible to have dynamic paths to resources and be a
> managed repository at the same time.
> That is the first step.  Separate the dynamic 'get' logic out from the
> webdav put/set layer.
>
> The next step is to allow the 4 identified clients to work on GET of
> resources contained within the repository.
>
> The 4 clients.
> * Apache Maven 2
> * Apache Maven 1.1
> * Apache Maven 1.0
> * Apache Ivy
>
> The 4 types of data that is fetched from the repository.
> * Artifacts
> * Versioned Metadata.xml
> * Project (unversioned) Metadata.xml
> * Checksum files
>
> Since we hit collisions on the auto-discovery technique for maven 1 to
> maven 2 requests (ie: legacy vs default), the need to have a different
> 'view' to the repository is crucial.  (one such collision in naming is
> when a metadata.xml file is requested and the path is detected as a
> maven 1 resource.  there are more, but addressing each 'special case'
> will just result in a piece of code horribly convoluted and ultimately
> doomed to maintenance hell)
>
> Now instead of talking about layouts (legacy vs default) and paths as
> the means to an end, the idea of access or client identifiers in the URL
> was discussed.  /get/${accessor_id}/${repo_id}/${resource}
>
> I'm about to rip it apart and implement it as proposed, as I want to see
> it work, and no one has yet to propose a different viable solution to
> the issue.
>
> This support is important in archiva, and we are getting close to a 1.0
> release.
>
> - Joakim
>
> Brett Porter wrote:
> > We're not really getting towards an answer here, just more spinning
> > around the questions.
> >
> > Please correct me if I'm wrong - but I believe that the get vs put
> > separation is for reasons entirely separate from the client
> > identification.
> >
> > If that is the case, do we agree that /repository and /webdav are
> > appropriate markers for those two requests?
> >
> > Now, returning to the issue of identifying the client - sorry, I don't
> > really understand why we can't identify the format from the URL. It
> > used to do it just fine. We occasionally had a glitch, and the code to
> > do it for m1 was gruesome, but it worked. I also don't understand what
> > is special about m1.1 - was something added that helped in the
> > identification?
> >
> > If we are going to have to put some sort of identification in the URL
> > we need to start deciding how that is going to look and be configured.
> > I really wasn't happy with the long URLs proposed before. I can think
> > of a couple of alternatives, but would prefer to look at the necessity
> > for it first.
> >
> > - Brett
> >
> > On 31/07/2007, at 5:17 AM, Joakim Erdfelt wrote:
> >
> >> Both of those choices do not provide the ability for the client to
> >> identify itself.
> >> Maven doesn't do it.
> >> Wagon doesn't do it.
> >> Ivy doesn't do it.
> >>
> >> So we are left with having some identification of the client via the
> >> URL.
> >>
> >> The long term future direction of Archiva is to support as many
> >> clients as possible.
> >> It is myopic to assume that everyone is going to use Maven 2.
> >>
> >> Archiva 1.0 should support Maven 2, Maven 1.0, Maven 1.1, and Ivy
> >> (all Apache projects).
> >>
> >> Currently, Maven 2, Maven 1.1, and Ivy are easily supported, we have
> >> problems supporting Maven 1.0 with the auto-discovery approach.
> >>
> >> I'm sure we have unit tests for auto-discovering the type of request.
> >> Currently needs to support
> >>
> >> * Artifact for layout of type default.
> >> * Metadata for type default.
> >> * Checksum request for type default.
> >> * Artifact for layout of type legacy.
> >> * Metadata for type legacy.
> >> * Checksum request for type legacy.
> >>

Re: What is Archiva.NEXT ?

[nicolas de loof]

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

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

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

To avoid any URL conflict, we could :

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

Nico.
2007/7/30, Brett Porter <[EMAIL PROTECTED]>:
>
> Joakim,
>
> Did we ever reach agreement on the format of these URLs? It'd be
> great to get it nailed down before beta-1 rolls out :)
>
> Cheers,
> Brett
>
> On 04/07/2007, at 11:28 AM, Brett Porter wrote:
>
> > So, last time this topic came up, there was disagreement on the /
> > get/ interface.
> >
> > Regarding using /get/ instead of just /repository/ URL as is, I
> > said (<[EMAIL PROTECTED]>)...
> > "Ok, while I'd definitely prefer to make it work, if it can't then
> > I'd prefer we made the change in the other direction (the default
> > repository URL is get only, we have /repository-id/webdav/ as the
> > webdav exposure point)."
> > to which Nicolas agreed.
> >
> > We then diverged into discussing auto-discovery of the getId from
> > the path which there were technical reasons to not do.
> >
> > However, I do not want all repositories to look like /archiva/
> > repository/releases/get/maven2/. Yikes.
> >
> > Cheers,
> > Brett
> >
> > On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
> >
> >> Design.
> >>
> >> 1) Create DynamicGetServlet which parses 
> >> /get/${getId}/${getResource}
> >> 2) Create Maven1GetProvider which has an id "maven1", and serves
> >> artifacts / poms to it.
> >> 3) Create Maven2GetProvider which has an id "maven2", and serves
> >> artifacts / poms / metadata to it.
> >> 4) Test
> >> 5) Done.
> >>
> >> - Joakim
> >>
> >> Brett Porter wrote:
> >>> Sounds good. With the M1 client support, can you post a small
> >>> design proposal first since last I remember we didn't reach
> >>> consensus on how it should be implemented?
> >>>
> >>> - Brett
> >>>
> >>> On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
> >>>
>  I agree.
> 
>  I view 1.0-beta-1 as feature complete.
> 
>  The current missing features ...
>  * Reporting (about 80% there right now, just some UI pieces left
>  to hook up)
>  * Maven 1 Client Support (about 40% complete. need to hook up
>  DynamicGetServlet)
>  * Live documentation. (present in archiva.war)
> 
>  - Joakim
> 
>  Brett Porter wrote:
> >
> > On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
> >
> >> Archiva 1.0-alpha-2 is out in the wild... what's next?  1.0-
> >> beta-1
> >> seems reasonable, but /topic in #archiva says "coming soon, the
> >> Archiva 1.0 (the "Ship It" release)".
> >
> > I was kidding (but that should be the focus from now on. Get it
> > done.) I agree 1.0-beta-1 is next - it should be feature complete.
> >
> >> - Brett
> >
> 
> 
>  --
>  - Joakim Erdfelt
>   [EMAIL PROTECTED]
>   Open Source Software (OSS) Developer
> >>>
> >>
> >>
> >> --
> >> - Joakim Erdfelt
> >>  [EMAIL PROTECTED]
> >>  Open Source Software (OSS) Developer
>

Re: service layer API proposal

[nicolas de loof]

You're right, the layout used by the managedRepository to store artifacts is
specified in its configuration, and the SVN code requires the request to
follow this layout. But the layout used to request an artifact from maven1
or maven2 is simple to detect.

The fact that the managedRepository internally use a filesystem layout to
store artifact is not visible, as the servlet layer can request for
ArtifactReference. Having this abstraction makes easy to convert any
incoming request from any supported layout to ArtifactReference, and then
from ArtifactReference to a File in managed repo.

So the difficulty dor auto-detecting request layout is only in the servlet
layer. It can select the valid BidirectionalLayout based on determinist URL
mappings "/{layoutId}/{repoId}/{path}" or based on auto-detection
"/repository/{repoId}/{path}", as I propose in MRM-412.



I mean /repository/{repoId}/{path} can detect legacy vs default maven
> layout
> easily based on number of "/" in the path. If the apt path (for example)
> overlaps with another supported layout, we simply need to provide an
> alternative /apt/{repoId}/{path}. "repository" would then simply be a
> reserved keyword for "autodetect requested type".
One point.  The layout is currently determined by the setting specified
on the {repoId}, not based on the number of "/" in the path.

- Joakim

Re: service layer API proposal

[nicolas de loof]

I agree with Brett about moving the DAV Url to a specific entry, as it
requires some specific handlign of GET as Joakim exposed to be compatible
with no-so-compliant Dav clients.

Based on this, if we access the repository as Dav via
/webdav/{repoId}/{path}, and map the /repository/{repoId}/{path} to a new
Get servlet, wy couldn't we combine layout detection with specific URLS ?

I mean /repository/{repoId}/{path} can detect legacy vs default maven layout
easily based on number of "/" in the path. If the apt path (for example)
overlaps with another supported layout, we simply need to provide an
alternative /apt/{repoId}/{path}. "repository" would then simply be a
reserved keyword for "autodetect requested type".


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


Splitting up this discussion ...

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

Example:
A maven 2 client can request either of these format URLs.

http://machine.com/repository/internal/commons-lang/poms/commons-lang-2.1.pom

http://machine.com/repository/internal/commons-lang/commons-lang/2.1/commons-lang-2.1.pom

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

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

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

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

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

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

- Joakim

Brett Porter wrote:
> I agree. Any reason we can't use detection?
>
> Also, any reason why the handler for downloading from the /repository/
> can't be this get servlet instead of dav servlet? We probably don't
> want to add new ways to download from the repository for the same
> reason we removed /proxy/. I realise you can only map one servlet, but
> the servlet could delegate all operations other than get() to the dav
> implementation.
>
> Anyway, not really sure of the implementation, just don't like 'get'
> as a name :)
>
> I also don't agree on the repository storage format. I don't see any
> reason this can't be configurable, and I think it's useful to be able
> to run on an existing repo, or should we ever change the m2 format in
> future.
>
> - Brett
>
> On 06/06/2007, at 4:18 AM, nicolas de loof wrote:
>
>> The "/get/{implementation-id}/{layout-path}" is an interesting option.
>>
>> Where would you place the target managed repository in such an URL ?
>>
>> The only thing I don't like in this solution is that it doesn't work
>> based
>> on an auto-detection of the requested format. I'd prefer the servlet to
>> search for an implementation that accepts the requested path, so that
>> the
>> current "/repository/id/{layout}" would be valid for any supported
>> layout.
>>
>>
>> 2007/6/5, Joakim Erdfelt <[EMAIL PROTECTED]>:
>>>
>>> We have 2 concepts that are co-mingled right now.
>>>
>>> 1) Getting an artifact from Archiva.
>>> 2) Deploying an artifact to Archiva.
>>>
>>> This proposal should focus on #1, Getting an artifact from Archiva.
>>> (As for #2, that can remain the realm of the current DavServlet
>>> implementation)
>>>
>>> I always pictured this as a new GetArtifactServlet.
>>>
>>> Lets say we have it mapped to the "/get" servlet mapping.
>>> The following urls would all point to the same artifact.
>>>
>>> : Basic Format for maven 1 clients.
>>>
>>>
http://hostname.com/archiva/get/maven1/org.apache.maven.wagon/jars/wagon-scm-1.0-alpha-3.jar
>>>
>>> : Basic Format for maven 2 clients.
>>>
>>>
http://hostname.com/archiva/get/maven2/org/apache/maven/wagon/wagon-scm/1.0-alpha-3/wagon-scm-1.0-alpha-3.jar
>>>
>>&g

service layer API proposal

[nicolas de loof]

Hello,

To enhance archiva-1.0 support for maven1, I'd like to introduce a layer
between DavServlet and repository proxies connectors.
As Joakim suggested, this is the scope of the Dynamic Artifact Serving Layer
in archiva roadmap.

I propose this API :

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

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

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

What's your opinion ?

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

[nicolas de loof]

I allready noticed this no-update-check issue on 0.9 in MRM-320, but maybe I
wasn't clear as it was closed as "won't fix".

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

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



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


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

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

- Joakim

nicolas de loof wrote:
> I just submitted MRM-412 and attached a patch.
>
> This issue adds support for any layout to the DavServlet :
> Requesting "/javax.servlet/jars/servlet-api-2.3.jar" or
> "/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar" will auto-detect
the
> layout used for the request (based on configured layouts in archiva)
> and use
> it to build the ArchivaArtifact object.
> This requires the BidirectionalRepositoryLayout interface to be
> enhanced to
> add detection of valid path.
>
> please review.
>
>
> I also notice the ProxiedDavServer does check for the requested file to
> exist in managed repo before trying to proxy it. Doesn't this bypass any
> update strategy configured in proxies ? Perhaps I missed something ?
>
>
> 2007/6/4, Joakim Erdfelt <[EMAIL PROTECTED]>:
>>
>> doh!  *I* never voted on this. :-)
>>
>> +1 to release.
>>
>> - Joakim
>>
>> Joakim Erdfelt wrote:
>> > Archiva 1.0-alpha-1 was tagged and built this afternoon.
>> >
>> > The proposed distribution, including binary distributions, and
>> > signatures can be found here:
>> >
>> >  http://people.apache.org/builds/maven/archiva/1.0-alpha-1/
>> >
>> > To keep up with the trend started by Wendy Smoak (sorta):
>> > The 1.0-alpha-1 staged copy was setup and configured to point to
>> > a pre-built repository, and then used to build the next archiva
>> > snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.
>> >
>> > This will be Archiva's first release with a proper database, and
>> > is intended to get a testable baseline of the archiva feature set
>> > into the hands of all interested individuals.
>> >
>> > The list of issues identified and closed with this release can
>> > be found below:
>> >
>> >  Archiva 1.0-alpha-1 Release Notes:
>> >
>> >
>>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443
>>
>> >
>> >
>> > This is an alpha release, and as such, has bugs.
>> >
>> > Once people have a chance to kick the prototype tires, and look
>> around,
>> > the most urgent jira tickets will be addressed quickly for a
>> 1.0-alpha-2
>> > release, with an expected release 1 to 2 weeks after this one.
>> >
>> > Known issues include documentation, problems with proxying, problems
>> > running the webapp on Tomcat, missing reporting, empty or inaccurate
>> > dependency tree information, and poor grammar.
>> > These and other issues can be tracked at the URL below:
>> >
>> >  Archiva 1.0-alpha-2 Open Issues:
>> >
>>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518
>>
>> >
>> >
>> > Once you have had a chance to examine the distribution, please cast
>> > your vote.  We welcome votes and feedback from all community members.
>> >
>> > [ ]  +1  Release it!
>> > [ ]   0
>> > [ ]  -1  Don't release it, because...
>> >
>> > 72 hours ends Monday afternoon (GMT -5)
>> > If you need more time, just ask.
>> >
>>
>>
>> --
>> - Joakim Erdfelt
>>   Committer and PMC Member, Apache Maven
>>   Archiva Developer
>>   [EMAIL PROTECTED]
>>   [EMAIL PROTECTED]
>>   Alpaca Founding Member

adding relocation support

[nicolas de loof]

I'd like to add support for archiva-side relocation for maven1 (as in
archiva 0.9)

this requires to get the requested artifact POM and override the
ArtifactReference object prior to fetching the proxy-connectors.
As the ProxiedDavServer make the call to connectors I'll have to place this
relocation-handling code in the ProxiedDavServer, that may not be the better
place.
What architecture would you suggest for an "artifact pre-processor" used as
an interceptor between the DavServer and the managedRepository and it's
proxies ?

Nico.

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

[nicolas de loof]

I just submitted MRM-412 and attached a patch.

This issue adds support for any layout to the DavServlet :
Requesting "/javax.servlet/jars/servlet-api-2.3.jar" or
"/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar" will auto-detect the
layout used for the request (based on configured layouts in archiva) and use
it to build the ArchivaArtifact object.
This requires the BidirectionalRepositoryLayout interface to be enhanced to
add detection of valid path.

please review.


I also notice the ProxiedDavServer does check for the requested file to
exist in managed repo before trying to proxy it. Doesn't this bypass any
update strategy configured in proxies ? Perhaps I missed something ?


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


doh!  *I* never voted on this. :-)

+1 to release.

- Joakim

Joakim Erdfelt wrote:
> Archiva 1.0-alpha-1 was tagged and built this afternoon.
>
> The proposed distribution, including binary distributions, and
> signatures can be found here:
>
>  http://people.apache.org/builds/maven/archiva/1.0-alpha-1/
>
> To keep up with the trend started by Wendy Smoak (sorta):
> The 1.0-alpha-1 staged copy was setup and configured to point to
> a pre-built repository, and then used to build the next archiva
> snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.
>
> This will be Archiva's first release with a proper database, and
> is intended to get a testable baseline of the archiva feature set
> into the hands of all interested individuals.
>
> The list of issues identified and closed with this release can
> be found below:
>
>  Archiva 1.0-alpha-1 Release Notes:
>
>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443
>
>
> This is an alpha release, and as such, has bugs.
>
> Once people have a chance to kick the prototype tires, and look around,
> the most urgent jira tickets will be addressed quickly for a 1.0-alpha-2
> release, with an expected release 1 to 2 weeks after this one.
>
> Known issues include documentation, problems with proxying, problems
> running the webapp on Tomcat, missing reporting, empty or inaccurate
> dependency tree information, and poor grammar.
> These and other issues can be tracked at the URL below:
>
>  Archiva 1.0-alpha-2 Open Issues:
>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518
>
>
> Once you have had a chance to examine the distribution, please cast
> your vote.  We welcome votes and feedback from all community members.
>
> [ ]  +1  Release it!
> [ ]   0
> [ ]  -1  Don't release it, because...
>
> 72 hours ends Monday afternoon (GMT -5)
> If you need more time, just ask.
>


--
- Joakim Erdfelt
  Committer and PMC Member, Apache Maven
  Archiva Developer
  [EMAIL PROTECTED]
  [EMAIL PROTECTED]
  Alpaca Founding Member

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

[nicolas de loof]

You're right, I missunderstood the default configuration of network proxies.
I just had to reconfigure the network proxies to point to my managed repo.

What is the default "internal" managed repo ?


2007/6/4, Fabrice Bellingard <[EMAIL PROTECTED]>:


+1, I'm happy with it already. :-)

Nicolas, getting artifacts from proxied remote repositories works fine for
me (at least it used to 3 days ago...). If I can help...

Fabrice.

On 6/4/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> +1 as a new clean codebase for enhancements, based on 0.9 features set.
>
> My personnal feedback on current features :
>
> + Verry clean configuration UI
> - Getting artifacts from a proxied repository doesn't work
> - Lack of support for Maven 1 (requests are not converted to get
artifacts
> from a maven2 managed repo)
> - wagon-provider-api 1.0 has a ConcurrentModificationException issue
> (WAGON-79)
>
>
> 2007/6/4, Maria Odea Ching <[EMAIL PROTECTED]>:
> >
> > +1
> >
> > Everything on the release notes seems to be in place.
> > Thanks Joakim :-)
> >
> > -Deng
> >
> > Joakim Erdfelt wrote:
> > > Archiva 1.0-alpha-1 was tagged and built this afternoon.
> > >
> > > The proposed distribution, including binary distributions, and
> > > signatures can be found here:
> > >
> > >  http://people.apache.org/builds/maven/archiva/1.0-alpha-1/
> > >
> > > To keep up with the trend started by Wendy Smoak (sorta):
> > > The 1.0-alpha-1 staged copy was setup and configured to point to
> > > a pre-built repository, and then used to build the next archiva
> > > snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.
> > >
> > > This will be Archiva's first release with a proper database, and
> > > is intended to get a testable baseline of the archiva feature set
> > > into the hands of all interested individuals.
> > >
> > > The list of issues identified and closed with this release can
> > > be found below:
> > >
> > >  Archiva 1.0-alpha-1 Release Notes:
> > >
> > >
> >
>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443
> > >
> > >
> > > This is an alpha release, and as such, has bugs.
> > >
> > > Once people have a chance to kick the prototype tires, and look
> around,
> > > the most urgent jira tickets will be addressed quickly for a
> 1.0-alpha-2
> > > release, with an expected release 1 to 2 weeks after this one.
> > >
> > > Known issues include documentation, problems with proxying, problems
> > > running the webapp on Tomcat, missing reporting, empty or inaccurate
> > > dependency tree information, and poor grammar.
> > > These and other issues can be tracked at the URL below:
> > >
> > >  Archiva 1.0-alpha-2 Open Issues:
> > >
> >
>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518
> > >
> > >
> > > Once you have had a chance to examine the distribution, please cast
> > > your vote.  We welcome votes and feedback from all community
members.
> > >
> > > [ ]  +1  Release it!
> > > [ ]   0
> > > [ ]  -1  Don't release it, because...
> > >
> > > 72 hours ends Monday afternoon (GMT -5)
> > > If you need more time, just ask.
> > >
> >
> >
>

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

[nicolas de loof]

+1 as a new clean codebase for enhancements, based on 0.9 features set.

My personnal feedback on current features :

+ Verry clean configuration UI
- Getting artifacts from a proxied repository doesn't work
- Lack of support for Maven 1 (requests are not converted to get artifacts
from a maven2 managed repo)
- wagon-provider-api 1.0 has a ConcurrentModificationException issue
(WAGON-79)


2007/6/4, Maria Odea Ching <[EMAIL PROTECTED]>:


+1

Everything on the release notes seems to be in place.
Thanks Joakim :-)

-Deng

Joakim Erdfelt wrote:
> Archiva 1.0-alpha-1 was tagged and built this afternoon.
>
> The proposed distribution, including binary distributions, and
> signatures can be found here:
>
>  http://people.apache.org/builds/maven/archiva/1.0-alpha-1/
>
> To keep up with the trend started by Wendy Smoak (sorta):
> The 1.0-alpha-1 staged copy was setup and configured to point to
> a pre-built repository, and then used to build the next archiva
> snapshot (1.0-alpha-2-SNAPSHOT) in archiva/trunk.
>
> This will be Archiva's first release with a proper database, and
> is intended to get a testable baseline of the archiva feature set
> into the hands of all interested individuals.
>
> The list of issues identified and closed with this release can
> be found below:
>
>  Archiva 1.0-alpha-1 Release Notes:
>
>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10980&styleName=Html&version=13443
>
>
> This is an alpha release, and as such, has bugs.
>
> Once people have a chance to kick the prototype tires, and look around,
> the most urgent jira tickets will be addressed quickly for a 1.0-alpha-2
> release, with an expected release 1 to 2 weeks after this one.
>
> Known issues include documentation, problems with proxying, problems
> running the webapp on Tomcat, missing reporting, empty or inaccurate
> dependency tree information, and poor grammar.
> These and other issues can be tracked at the URL below:
>
>  Archiva 1.0-alpha-2 Open Issues:
>
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10980&fixfor=13518
>
>
> Once you have had a chance to examine the distribution, please cast
> your vote.  We welcome votes and feedback from all community members.
>
> [ ]  +1  Release it!
> [ ]   0
> [ ]  -1  Don't release it, because...
>
> 72 hours ends Monday afternoon (GMT -5)
> If you need more time, just ask.
>

Re: [VOTE] Release source distribution for Archiva 0.9-alpha-2

[nicolas de loof]

+1

2007/5/22, Arnaud HERITIER <[EMAIL PROTECTED]>:


+1 also

arnaud

On 21/05/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> +1, looks right to me.
>
> Some of the directories probably aren't necessary in a future release
> (meeper, design, etc), but works for this one.
>
> - Brett
>
> On 19/05/2007, at 10:15 AM, Wendy Smoak wrote:
>
> > I'd like to release a buildable source distribution to go along with
> > Archiva 0.9-alpha-2.
> >
> > Please review the archiva-0.9-alpha-2-src.tar.gz file and its
> > companion checksums and signature, and then cast your vote.
> >
> > * http://people.apache.org/builds/maven/archiva/0.9-alpha-2/
> >
> > Because there is no source assembly configured in the Archiva build,
> > this distribution was prepared by exporting the tag from svn, and
> > adding the LICENSE/NOTICE files.
> >
> > Thanks,
> > --
> > Wendy
> > http://wiki.wsmoak.net/cgi-bin/wiki.pl?Archiva09Alpha2Release#source
>



--
..
Arnaud HERITIER
..
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...

Re: [VOTE] Release Archiva 0.9-alpha-2

[nicolas de loof]

+1

2007/5/14, Wendy Smoak <[EMAIL PROTECTED]>:


Archiva 0.9-alpha-2 was tagged and built this afternoon.  For extra
credit, the entire build was done with an Archiva 0.9 snapshot running
locally, configured as mirrorOf=* and proxying all necessary remote
repositories.  I also tested this configuration with the Struts 1 and
Struts 2 builds.

The proposed distribution, including signatures, can be found here:

   http://people.apache.org/builds/maven/archiva/0.9-alpha-2/

This will be Archiva's first release, and is intended to wrap up
development of the original codebase to make way for 1.0.  Known
issues include problems running the webapp on Tomcat, and limitations
on the number of artifacts this version can handle.

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

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

72 hours ends Wednesday night (GMT -7) but I probably won't do
anything further with it until Friday afternoon.  If you need more
time, just ask.

Thanks,
--
Wendy Smoak
http://wiki.wsmoak.net/cgi-bin/wiki.pl?Archiva09Alpha2Release

Re: question about POMs in (new) trunk

[nicolas de loof]

I've made some test on minimalist POM hierarchy and having multi-level
parents OR setting version using dependencyManagement doesn't break the
ability to setup eclipse without having the project installed in local
repository..

You can take a look at my poms here : http://ndeloof.free.fr/temp/poms.zip

test (pom)
|_ test-one (pom)
||_ sub-test-one (jar)
|_test-two (pom)
|_ sub-test-two (jar) with dependency on sub-test-one

mvn eclipse:eclipse creates the expected .classpath in sub-test-two and
doesn't requires the jars in local repo neither tries to download them.


I don't understand why this fails with archiva-webapp



2007/5/3, nicolas de loof <[EMAIL PROTECTED]>:


I allready use this for my corporate projects with not having this issue :

as maven knows the projects are modules from the same parent POM, it
resolves such modules dependencies as inter-project dependencies under
eclipse and DOESN'T require the project to be installed in local repo.

Some prior Eclipse plugin version had the issue to require the compile
phase to be executed before generating the eclipse configuration, and this
created troubles for many users taht fall in the same situation : checkout
of an unstable project require to fix with vi... (vi is great but I also
like eclipse)

Maybe this issue relates to the two-level of parent POMs : archiva-webapp
and it's dependencies do not share the same direct parent.

2007/5/3, Joakim Erdfelt < [EMAIL PROTECTED]>:
>
> That's expected.
>
> On a fresh checkout/update, the modules do not exist in the local (or
> remote) repositories yet.
>
> When you run the eclipse:eclipse goal, it tries to resolve the
> dependencies, it can't as there is no information present in the
> repository system for those modules.
>
> Compile it first,  then run eclipse:eclipse, then import it into
> eclipse.
>
> - Joakim
>
>
> nicolas de loof wrote:
> > You're right, I missed it.
> >
> > This has a strange side effect : when I run mvn eclipse:eclipse from a
> > fresh
> > checkout, all inter-modules dependencies are unresolved :
> >
> > [INFO]
> >
> 
> > [ERROR] BUILD ERROR
> > [INFO]
> >
> 
> > [INFO] Failed to resolve artifact.
> >
> > Missing:
> > --
> > 1)
> >
> org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT
> >
> >
> >  Try downloading the file manually from the project website.
> >
> >  Then, install it using the command:
> >  mvn install:install-file
> > -DgroupId=
> org.apache.maven.archiva-DartifactId=archiva-database-consumers
> > \
> >  -Dversion=1.0-alpha-1-SNAPSHOT -Dpackaging=jar
> > -Dfile=/path/to/file
> >
> >  Path to dependency:
> >1)
> > org.apache.maven.archiva:archiva-webapp:war:1.0-alpha-1-SNAPSHOT
> >2)
> > org.apache.maven.archiva:archiva-scheduled:jar:1.0-alpha-1-SNAPSHOT
> >3)
> >
> org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT
> >
> > ...
> >
> >
> > I can't import all modules in Eclipse before mvn install is
> successfull.
> > This may create issues if the code in SVN has compilation failures due
> to
> > some unfortunate commit.
> >
> >
> > 2007/5/3, Andrew Williams <[EMAIL PROTECTED] >:
> >>
> >> I have not looked, but am guessing there is a dependencyManagement
> >> section in the parent pom.
> >>
> >> Andy
> >>
> >> On 3 May 2007, at 11:45, nicolas de loof wrote:
> >>
> >> > The POMs in the new trunk don't set versions for dependencies on
> other
> >> > arhiva modules. Maven has no issue with that when running mvn
> install.
> >> >
> >> > I tried to do the same on my project and got error :
> >> > Validation Messages:
> >> >
> >> >[0]  'dependencies.dependency.version' is missing for
> >> > com.capgemini.quickstart:quickstart-model
> >> >
> >> > Reason: Failed to validate POM
> >> >
> >> >
> >> > I don't see any special version setting in archiva. Did I miss
> >> > something ?
> >> >
> >> > Nico.
> >>
> >>
> >
>
>

Re: question about POMs in (new) trunk

[nicolas de loof]

I allready use this for my corporate projects with not having this issue :
as maven knows the projects are modules from the same parent POM, it
resolves such modules dependencies as inter-project dependencies under
eclipse and DOESN'T require the project to be installed in local repo.

Some prior Eclipse plugin version had the issue to require the compile phase
to be executed before generating the eclipse configuration, and this created
troubles for many users taht fall in the same situation : checkout of an
unstable project require to fix with vi... (vi is great but I also like
eclipse)

Maybe this issue relates to the two-level of parent POMs : archiva-webapp
and it's dependencies do not share the same direct parent.

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


That's expected.

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

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

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

- Joakim


nicolas de loof wrote:
> You're right, I missed it.
>
> This has a strange side effect : when I run mvn eclipse:eclipse from a
> fresh
> checkout, all inter-modules dependencies are unresolved :
>
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
>
> Missing:
> --
> 1)
>
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT
>
>
>  Try downloading the file manually from the project website.
>
>  Then, install it using the command:
>  mvn install:install-file
> -DgroupId=
org.apache.maven.archiva-DartifactId=archiva-database-consumers
> \
>  -Dversion=1.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
>
>  Path to dependency:
>1)
> org.apache.maven.archiva:archiva-webapp:war:1.0-alpha-1-SNAPSHOT
>2)
> org.apache.maven.archiva:archiva-scheduled:jar:1.0-alpha-1-SNAPSHOT
>3)
>
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT
>
> ...
>
>
> I can't import all modules in Eclipse before mvn install is successfull.
> This may create issues if the code in SVN has compilation failures due
to
> some unfortunate commit.
>
>
> 2007/5/3, Andrew Williams <[EMAIL PROTECTED]>:
>>
>> I have not looked, but am guessing there is a dependencyManagement
>> section in the parent pom.
>>
>> Andy
>>
>> On 3 May 2007, at 11:45, nicolas de loof wrote:
>>
>> > The POMs in the new trunk don't set versions for dependencies on
other
>> > arhiva modules. Maven has no issue with that when running mvn
install.
>> >
>> > I tried to do the same on my project and got error :
>> > Validation Messages:
>> >
>> >[0]  'dependencies.dependency.version' is missing for
>> > com.capgemini.quickstart:quickstart-model
>> >
>> > Reason: Failed to validate POM
>> >
>> >
>> > I don't see any special version setting in archiva. Did I miss
>> > something ?
>> >
>> > Nico.
>>
>>
>

Re: question about POMs in (new) trunk

[nicolas de loof]

You're right, I missed it.

This has a strange side effect : when I run mvn eclipse:eclipse from a fresh
checkout, all inter-modules dependencies are unresolved :

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file
-DgroupId=org.apache.maven.archiva-DartifactId=archiva-database-consumers
\
 -Dversion=1.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1) org.apache.maven.archiva:archiva-webapp:war:1.0-alpha-1-SNAPSHOT
   2)
org.apache.maven.archiva:archiva-scheduled:jar:1.0-alpha-1-SNAPSHOT
   3)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT
...


I can't import all modules in Eclipse before mvn install is successfull.
This may create issues if the code in SVN has compilation failures due to
some unfortunate commit.


2007/5/3, Andrew Williams <[EMAIL PROTECTED]>:


I have not looked, but am guessing there is a dependencyManagement
section in the parent pom.

Andy

On 3 May 2007, at 11:45, nicolas de loof wrote:

> The POMs in the new trunk don't set versions for dependencies on other
> arhiva modules. Maven has no issue with that when running mvn install.
>
> I tried to do the same on my project and got error :
> Validation Messages:
>
>[0]  'dependencies.dependency.version' is missing for
> com.capgemini.quickstart:quickstart-model
>
> Reason: Failed to validate POM
>
>
> I don't see any special version setting in archiva. Did I miss
> something ?
>
> Nico.

Re: question about POMs in (new) trunk

[nicolas de loof]

Adding " ${project.version} " on my modules dependencies
solves this.
What maven hack is used by archiva ???



2007/5/3, nicolas de loof <[EMAIL PROTECTED]>:


The POMs in the new trunk don't set versions for dependencies on other
arhiva modules. Maven has no issue with that when running mvn install.

I tried to do the same on my project and got error :
Validation Messages:

[0]  'dependencies.dependency.version' is missing for
com.capgemini.quickstart:quickstart-model

Reason: Failed to validate POM


I don't see any special version setting in archiva. Did I miss something ?


Nico.

Re: Complete: trunk version upgraded to 1.0-alpha-1-SNAPSHOT

[nicolas de loof]

Thanks for the work done on the branch.

Nico.


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


The merge is complete.
Trunk is now on version 1.0-alpha-1-SNAPSHOT using the former database
branch.

Old trunk is now located in
https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-0.9

- Joakim

Joakim Erdfelt wrote:
> Steps 1-4 are now complete.
> Working on Step 5 (make version in trunk 1.0-alpha-1-SNAPSHOT) now ...
>
> - Joakim
>
> Joakim Erdfelt wrote:
>> Ok.
>>
>> Here's the vote breakdown.
>>
>> option A - Make the branch the new trunk.
>> * Emmanuel Venisse
>> * Arnaud Heriter
>> * Nicolas De Loof
>> * Jesse McConnell
>> * Brett Porter
>> * Wendy Smoak
>>
>> option B - Merge the branch into the existing trunk.
>> * Maria Odea Ching
>>
>> option C - Do not merge the branch into trunk.
>> * (n/a)
>>
>> Looks like option A wins!
>>
>> The current plan
>>
>> 1) Identify the changes since the branch has been made.
>>Branch was created on March 15, 2007 - on revision 518676
>> 2) Merge in changes made on trunk since branch into the branch.
>> 3) Rename the current trunk as branch-0.9
>> 4) Rename the archiva-jpox-database branch as the new trunk.
>> 5) Set the versions in the trunk to 1.0-alpha-1-SNAPSHOT
>> 6) Announce completion of merge to archiva-dev
>> 7) Continue working on admin screens.
>> 8) Once admin screens are stable, get the ball rolling on a
>> 1.0-alpha-1 release.
>>
>> - Joakim Erdfelt
>

Re: Let's release Archiva

[nicolas de loof]

I just mean that I don't understand why we need a release if the goal is not
to make it attractive to new users, but just tag the existing code some of
us allready use in production. If the trunk changes, I'll update my patches
to support the features I need (I allready did it when the Dav servlet
replaced the proxy servlet).

Maybe I simply have to learn "ASF release guidelines", as I never was
implied in an apache project release before.

That beeing said, I have no objection about releasing a 0.9, if you consider
this usefull.

Nico.

2007/4/29, Wendy Smoak <[EMAIL PROTECTED]>:


[moved from the branch merge vote thread]

On 4/27/07, nicolas de loof <[EMAIL PROTECTED]> wrote:

> I also use this codebase for my corporate job and will contribute to
> maintain supported features in future releases. I just don't understand
why
> a "0.9" release would change about the trunk code to be maintained or
not.
> Do you just mean that having a (pre)release would make the supported
> features included in the roadmap ? We still have to re-code them in the
> branch-code.

I'm not sure I understand what you mean.

I'd like to capture the work you and Arnaud have already done, get
those patches applied and release it as 0.9-alpha-2.  (or possibly -3
depending on whether I get all the i's dotted and t's crossed for
release requirements.)

I have no plans beyond a single PMC-approved release of this codebase.
I personally don't see the point of adding features to it given that
the new branch will soon arrive.

In addition to wanting it released because I'm using it, we're also on
the wrong side of the ASF release guidelines as they currently stand,
and need to correct that.

--
Wendy

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

An 0.9 release is not intended to attract users, it's intended to deal
with the fact that it already *has* users, and should have been
officially released a long time ago.

I'm not planning to make a big deal of it, a quiet mention on the user
list and a link at the bottom of the download page is plenty.
Personally, I have this code in production and would like to see this
line of development nicely wrapped up rather than just abandoned.




I also use this codebase for my corporate job and will contribute to
maintain supported features in future releases. I just don't understand why
a "0.9" release would change about the trunk code to be maintained or not.
Do you just mean that having a (pre)release would make the supported
features included in the roadmap ? We still have to re-code them in the
branch-code.


--

Wendy

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

According to this I would vote for option A (move branch to trunk).

Hard refactoring has been made on branch, and trunk is now only a demo of
what archiva may look like some day. Releasing archiva 0.9 from trunk, even
in alpha, is not a good idea IMHO as this will not reflect the real
development status. Maybe I missundertand "alpha" keyword.

I also would like a archiva release to come out. Having a working app from
the branch with limited features would be better IMHO than publishing some
"alpha" with features that have been dropped from the codebase.

Nico


2007/4/27, Emmanuel Venisse <[EMAIL PROTECTED]>:




nicolas de loof a écrit :
> 2007/4/27, Emmanuel Venisse <[EMAIL PROTECTED]>:
>>
>>
>>
>> nicolas de loof a écrit :
>> > I just checked out the branch and ran mvn install. I got all test
>> failures
>> > for Archiva Database (on windows 2000)
>>
>> Can you send the test outputs? All build fine on linux and Win XP.
>
>
>
> [solved]
> as I'm running behind archiva configured *, and current
archiva
> trunk doesn't update snapshots, my snapshots dependencies were not up to
> date.
>
> I now can build the branch and deploy it as expected on tomcat with a
newly
> created db.
>
>
> I just can't access admin space so cannot do any test to check for
> supported
> features...
>
> settings
> ->
>
> java.lang.NullPointerException:
>
org.apache.maven.archiva.web.action.admin.RepositoriesAction.setServletRequest
(RepositoriesAction.java:109)
>
>
> managed or proxied repositories
> ->
>
> There is no Action mapped for namespace /admin and action name
> managedRepositories.
>
>
>
> Did I miss something ?
> Is this expected to work ?
>

managedRepositories and proxiedRepositories actions don't exist now and
are replaced by repositories action like the settings link.
I have the same NPE but I think joakim doesn't have finished this part as
he worked on it yesterday.

I get an other NPE on
org.apache.maven.archiva.scheduled.RepositoryTaskJob.execute(
RepositoryTaskJob.java:59)

Emmanuel

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

2007/4/27, Emmanuel Venisse <[EMAIL PROTECTED]>:




nicolas de loof a écrit :
> I just checked out the branch and ran mvn install. I got all test
failures
> for Archiva Database (on windows 2000)

Can you send the test outputs? All build fine on linux and Win XP.




[solved]
as I'm running behind archiva configured *, and current archiva
trunk doesn't update snapshots, my snapshots dependencies were not up to
date.

I now can build the branch and deploy it as expected on tomcat with a newly
created db.


I just can't access admin space so cannot do any test to check for supported
features...

settings
->

java.lang.NullPointerException:

org.apache.maven.archiva.web.action.admin.RepositoriesAction.setServletRequest(RepositoriesAction.java:109)

managed or proxied repositories
->

There is no Action mapped for namespace /admin and action name
managedRepositories.



Did I miss something ?
Is this expected to work ?

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

+1

current trunk will then be released as a "proof-of-concept" or demo, as the
code base and configuration changes for 1.0.


2007/4/27, Arnaud HERITIER <[EMAIL PROTECTED]>:


I vote A. We switch the branch and the trunk.
I'll apply Nicolas' patches on this branch and we'll release a new
version.
What it is important is to document it on the web site to inform our users
that the trunk isn't stable and that we released some alpha.

Arnaud

On 27/04/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> I just checked out the branch and ran mvn install. I got all test
failures
> for Archiva Database (on windows 2000)
>
> I then built with "-Dmaven.test.skip=true" and deployed on my local
tomcat
> (with old database deleted)
>
> Got some funy ascii-art in logs, but some errors
>
> "org.apache.maven.archiva.database.ArchivaDatabaseException: Error in
JDO
> during
> get of Database object id [internal] of type
> org.apache.maven.archiva.model.Arch
> ivaRepositoryModel using no fetch-group"
>
> .. and accessing localhost:8080/archiva :
>
> Caught Exception while registering Interceptor class
> pssEnvironmentCheckInterceptor - [unknown location]
> org.codehaus.plexus.xwork.PlexusObjectFactory.buildInterceptor(
> PlexusObjectFactory.java:152)
> ...
>
>
> Maybe the database refactoring is required, but IMHO the current
> branch isn't ready for becoming the trunk ...
>
>
>
>
>
>
> 2007/4/27, Emmanuel Venisse <[EMAIL PROTECTED]>:
> >
> > It's ok now, thanks.
> >
> > The branch seems to be good and well organized.
> > Even if I found some NPE when I used the webapp, I'm +1 to use it as
> > trunk.
> >
> > I don't think you'll can do option B easily, so I vote to option A.
You
> > can move the actual trunk to branches/archiva-0.9.x until the new
trunk
> is
> > stable.
> >
> > Emmanuel
> >
> > Joakim Erdfelt a écrit :
> > > Please try again.
> > >
> > > All of the unit tests now work on windows.
> > >
> > > - Joakim
> > >
> > > Emmanuel Venisse wrote:
> > >> Option C: Tests don't work on windows so I can't test it.
> > >>
> > >> When they'll be fixed, I'll be for Option B.
> > >>
> > >> Emmanuel
> > >>
> > >> Joakim Erdfelt a écrit :
> > >>> Lots of work has been done in the archiva database branch in the
> past
> > >>> 2 months.
> > >>>
> > >>> It has come time to start the merge back into trunk and get the
help
> > >>> of others to finish off the work.
> > >>>
> > >>> I wanted to point people to the branch and let them take a look
> > >>> around, and then vote.
> > >>>
> > >>> As I see it we have 3 options.
> > >>>
> > >>> option A [ ] Make the branch the new trunk.
> > >>> option B [ ] Merge the branch into the existing trunk.
> > >>> option C [ ] -1 Do not merge the branch into trunk.
> > >>>
> > >>> I'll wait the usual 72 hours and tabulate the scores.
> > >>> Scores will be tabulated around 1:00am Sunday UTC.
> > >>>
> > >>> I favor option A personally, but I don't know what that will mean
to
> > >>> those people that have trunk currently checked out.
> > >>>
> > >>> The Branch:
> > >>>
> >
>
https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor
> > >>>
> > >>>
> > >>> The Good:
> > >>> 1) Completed Integration of JPOX Database into system.
> > >>> 2) Completely overhauled the repository scanning for performance,
> > >>> availability, resilience, and capabilities.
> > >>> 3) Completely overhauled the reporting system for growth and use
of
> > >>> the database.
> > >>>
> > >>> The Bad:
> > >>> 1) Admin screens have not yet been converted to the new
> > >>> configuration. (that's a priority for me ATM)
> > >>> 2) Automatic Artifact relocation on proxied requests has not been
> > >>> implemented.
> > >>> 3) Untested.
> > >>>
> > >>> I'm eager to get the other devs involved ASAP.
> > >>>
> > >>> While the vote is going on, I'll be alternating between Redback
> > >>> development and Archiva Admin Screen work.
> > >>>
> > >>> - Joakim Erdfelt
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

I just checked out the branch and ran mvn install. I got all test failures
for Archiva Database (on windows 2000)

I then built with "-Dmaven.test.skip=true" and deployed on my local tomcat
(with old database deleted)

Got some funy ascii-art in logs, but some errors

"org.apache.maven.archiva.database.ArchivaDatabaseException: Error in JDO
during
get of Database object id [internal] of type
org.apache.maven.archiva.model.Arch
ivaRepositoryModel using no fetch-group"

.. and accessing localhost:8080/archiva :

Caught Exception while registering Interceptor class
pssEnvironmentCheckInterceptor - [unknown location]

org.codehaus.plexus.xwork.PlexusObjectFactory.buildInterceptor(PlexusObjectFactory.java:152)
...


Maybe the database refactoring is required, but IMHO the current
branch isn't ready for becoming the trunk ...






2007/4/27, Emmanuel Venisse <[EMAIL PROTECTED]>:


It's ok now, thanks.

The branch seems to be good and well organized.
Even if I found some NPE when I used the webapp, I'm +1 to use it as
trunk.

I don't think you'll can do option B easily, so I vote to option A. You
can move the actual trunk to branches/archiva-0.9.x until the new trunk is
stable.

Emmanuel

Joakim Erdfelt a écrit :
> Please try again.
>
> All of the unit tests now work on windows.
>
> - Joakim
>
> Emmanuel Venisse wrote:
>> Option C: Tests don't work on windows so I can't test it.
>>
>> When they'll be fixed, I'll be for Option B.
>>
>> Emmanuel
>>
>> Joakim Erdfelt a écrit :
>>> Lots of work has been done in the archiva database branch in the past
>>> 2 months.
>>>
>>> It has come time to start the merge back into trunk and get the help
>>> of others to finish off the work.
>>>
>>> I wanted to point people to the branch and let them take a look
>>> around, and then vote.
>>>
>>> As I see it we have 3 options.
>>>
>>> option A [ ] Make the branch the new trunk.
>>> option B [ ] Merge the branch into the existing trunk.
>>> option C [ ] -1 Do not merge the branch into trunk.
>>>
>>> I'll wait the usual 72 hours and tabulate the scores.
>>> Scores will be tabulated around 1:00am Sunday UTC.
>>>
>>> I favor option A personally, but I don't know what that will mean to
>>> those people that have trunk currently checked out.
>>>
>>> The Branch:
>>>
https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor
>>>
>>>
>>> The Good:
>>> 1) Completed Integration of JPOX Database into system.
>>> 2) Completely overhauled the repository scanning for performance,
>>> availability, resilience, and capabilities.
>>> 3) Completely overhauled the reporting system for growth and use of
>>> the database.
>>>
>>> The Bad:
>>> 1) Admin screens have not yet been converted to the new
>>> configuration. (that's a priority for me ATM)
>>> 2) Automatic Artifact relocation on proxied requests has not been
>>> implemented.
>>> 3) Untested.
>>>
>>> I'm eager to get the other devs involved ASAP.
>>>
>>> While the vote is going on, I'll be alternating between Redback
>>> development and Archiva Admin Screen work.
>>>
>>> - Joakim Erdfelt
>>>
>>>
>>>
>>
>
>
>
>

Re: [VOTE] Merge Archiva Database Branch to Trunk

[nicolas de loof]

+1 option B [ ] Merge the branch into the existing trunk.

Nico.

2007/4/26, Joakim Erdfelt <[EMAIL PROTECTED]>:


Lots of work has been done in the archiva database branch in the past 2
months.

It has come time to start the merge back into trunk and get the help of
others to finish off the work.

I wanted to point people to the branch and let them take a look around,
and then vote.

As I see it we have 3 options.

option A [ ] Make the branch the new trunk.
option B [ ] Merge the branch into the existing trunk.
option C [ ] -1 Do not merge the branch into trunk.

I'll wait the usual 72 hours and tabulate the scores.
Scores will be tabulated around 1:00am Sunday UTC.

I favor option A personally, but I don't know what that will mean to
those people that have trunk currently checked out.

The Branch:

https://svn.apache.org/repos/asf/maven/archiva/branches/archiva-jpox-database-refactor

The Good:
1) Completed Integration of JPOX Database into system.
2) Completely overhauled the repository scanning for performance,
availability, resilience, and capabilities.
3) Completely overhauled the reporting system for growth and use of the
database.

The Bad:
1) Admin screens have not yet been converted to the new configuration.
(that's a priority for me ATM)
2) Automatic Artifact relocation on proxied requests has not been
implemented.
3) Untested.

I'm eager to get the other devs involved ASAP.

While the vote is going on, I'll be alternating between Redback
development and Archiva Admin Screen work.

- Joakim Erdfelt

Re: Let's release Archiva

[nicolas de loof]

patch is up to date and issue has been reopened (as previous patch was
applied but didn't work using the DAV "/repository" URI.

2007/4/11, Arnaud HERITIER <[EMAIL PROTECTED]>:


On 11/04/07, nicolas de loof <[EMAIL PROTECTED]> wrote:
>
> I have my archiva deployed and running, so I can wait for a merge for
any
> further enhancements. I allready had to adapt MRM153 patch for the
> "/proxy"
> to "/repository" URI changes. I'll follow changes made on trunk to
update
> my
> snapshot, and propose patches when required.


Did you attached the updated patches to the issues ?

Just for my info, as I missed original discution about branching, what
does
> this parallel work target as enhancement for archiva ?
>
> Nico.
>
> 2007/4/10, Wendy Smoak <[EMAIL PROTECTED]>:
> >
> > On 4/10/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> >
> > > Also, the work that is identified by MRM-153 + 211 + 212 are moot in
> the
> > > branch, as other, more fundamental solutions has been worked out for
> > > dealing with remote repositories, checksum policy, and maven 1
> clients.
> > ...
> > > Any release of trunk should be considered pre-1.0 (not even alpha-1)
> as
> > > it is so broken.
> >
> > Thanks for the detailed list of issues.  And I edited out a suggestion
> > to release it as 0.9 and leave the 1.0 version for the work on the
> > branch, so let's go with that, assuming...
> >
> > Arnaud, Nicolas, are you planning to work on trunk and get the fixes
> > in there, or are you content to wait on the branch?
> >
> > --
> > Wendy
> >
>

Re: Let's release Archiva

[nicolas de loof]

I'm using archiva in my company to manage our private repo (repo1 proxy +
some resticted jars).
I've tested archiva during 2 month. I've configured our old maven-proxy to
point to archiva, to test those MRM patches :

maven1 & maven2 users --> maven-proxy --> archiva --> repo1.maven.org/maven2

This allowed me to convert our corporate repo to maven2 layout and to clean
some artifacts locations.

I now have removed maven-proxy from the chain, so archiva get's more load.
To ensure all is working fine, many users dropped there local repository, so
that archiva had to serve lot's of jars.
Some users reported me HTTP 500 errors. A ConcurrencyModificationExceptions
was logged.

The wagon issue is not critical as the user can get the expected artifact by
running the build a second time.

Releasing archiva with this issue may place newbee users in the same
situation. They will the consider archiva to be buggy as they have issues
on existing builds as they do with simplier tools like maven-proxy. For this
reason, I consider this to be a blocker to make a public release.

My current deployed archiva is updated to Wagon 2.0-SNAPSHOT with WAGON-79
patch. There may be other similar issues on wagon listeners. But this
introduces a dependency on SNAPSHOTs. Maybe could htis be fixed in the
1.Xwagon branch ?

Nico.


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


Nicolas,

I'd been meaning to reply. We should get your patches applied first.
Would you be in favour then, or is the wagon issue a blocker?

- Brett

On 10/04/2007, at 3:18 PM, nicolas de loof wrote:

> I'm also using archiva for both my maven1 and maven2 projects.
>
> I'll just warn that there is a thread-safety issue with wagon
> (WAGON-79)
> that introduces ConcurrentModificationException.
>
> I applied MRM-153 + 211 + 212 patches to my snapshot build. This
> allow me to
> have only one repository for both maven versions. MRM-212 is a
> requirement
> to make archiva usable as a proxy on repo1.
>
> For those reason, I'd vote -1 (as a user) for a release based on
> current
> trunk.
>
> Nico.
>
>
>
>
> 2007/4/10, Brett Porter <[EMAIL PROTECTED]>:
>>
>> I'm also in favour of this. I've been using it myself, and it's
>> stable enough for my purposes.
>>
>> I've been holding back on asking the same thing as I know Joakim has
>> been doing significant work on the branch and I've been expecting
>> some details here any day now. Joakim - can you update us on what
>> you've been doing and how it will impact trunk?
>>
>> Based on that, I think we need to make a decision about whether to
>> cut a release from the current trunk for all those that have ended up
>> using it, or push forward with the new code. But either way, we need
>> a release now.
>>
>> - Brett
>>
>>
>> On 10/04/2007, at 1:48 PM, Wendy Smoak wrote:
>>
>> > I took a look at archiva/trunk, and the only remaining snapshot
>> > dependencies I see are from maven-app-configuration.  That vote has
>> > passed and is just waiting for the staged binaries to be copied
>> over
>> > to the synced repo.
>> >
>> > Once that's done, I'd like to tag and release archiva/trunk.  It
>> > works, it already has users, and we should have an official
>> release.
>> >
>> > Thoughts?
>> >
>> > --
>> > Wendy
>>