Re: Create artifacts library for downloaded IBM jar files.

[Yoav Landman]

On Thu, Jan 20, 2011 at 3:06 PM, Wendy Smoak  wrote:

> On Thu, Jan 20, 2011 at 6:51 AM, Jonathan Vila Lopez
>  wrote:
>
> > As the IBM MQSeries jars are not in the apache maven repositories, I have
> > downloaded the jars but now I would like to add to my Artifactory
> > repository. but I have to do that one jar by one.
>
> That would be something to ask the Artifactory folks.  Maybe they have
> a way to upload a bundle of jars at once.
>

Yes, you can create an artifact bundle (zip archive) and upload it to
Artifactory in one go or use repository import. Like Wendy suggested, it's
better if you ask on artifactroy-users for more details.


>
> It's probably just as easy to write a shell script to "mvn
> deploy:deploy-file ..." the list of jars though.
>
> > Is there any other better way to do that ? We are 4 developers and I
> would
> > like to avoid that all of us have to download the jars and put them in
> our
> > local repository.
>
> Adding them to your internal repo manager will solve that.
>
> --
> Wendy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Yoav

Re: License collection

[Yoav Landman]

You may also want to have a look at the Artifactory license addon, which
does exactly that - finds the licenses of all dependencies of a build
(including searching in parent poms) with the ability to assign
custom license information + generate a report with selective dependency
scopes. It is part of Artifactory Pro.

http://wiki.jfrog.org/confluence/display/RTF/License+Control

On Sat, Jan 22, 2011 at 6:01 AM, Rui Vilão  wrote:

> Hi,
>
> Thank you all for replying.
>
> As Stevo mentioned I'm using maven-license-plugin to generate headers as
> well. But I need to include the licenses of the dependencies I'm using in
> order to distribute my software. I believe it would be great if developers
> include the license in the license tag in order for plugins to collect and
> download them. The behavior would be something like the described here:
>
> http://mojo.codehaus.org/license-maven-plugin/
>
> like Wayne mentioned. As far as I can see there's no simple approach to do
> this, so I believe I will use the report plugin and collect them myself
> with
> my bare hands :p
>
> Anyway, thank you for your time!
>
> --
> Rui
>
> On Fri, Jan 21, 2011 at 7:26 PM, Kalle Korhonen
> wrote:
>
> > As Wayne mentioned, most of the modules contain an url to a license
> > rather than have it checked in. Perhaps you just need the license
> > report instead? The dependencies report of the mpir plugin has had a
> > license section for quite some time, I use it all the time. See e.g.
> > the dependency report of the mpir plugin itself:
> >
> >
> http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies.html
> > .
> >
> > Kalle
> >
> >
> > On Fri, Jan 21, 2011 at 9:30 AM, Rui Vilão  wrote:
> > > Hi all,
> > >
> > > I'm trying to automate licensing collection for my product. What I want
> > is
> > > simple: collect (i.e. download) all licenses of my dependencies and
> store
> > > them in a folder.
> > >
> > > Does anyone know if there's a plugin that does what I'm trying to
> > > accomplish? I've heard about license-maven-plugin (
> > > http://mojo.codehaus.org/license-maven-plugin/ ) but I couldn't even
> > > download it.
> > >
> > > Thanks in advance,
> > >
> > > Rui
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>



-- 
Yoav

Re: Migration to Maven 3.0.1 - Deploy fails with Error: 500 only for top most maven-metadata.xml

[Yoav Landman]

You can also upgrade Artifactory to 2.3.0+ which is compatible with the new
format, so you wouldn't need to specify the legacy deployment mode on the
client side.

On Fri, Jan 7, 2011 at 11:28 PM, vratnagiri  wrote:

>
> Thanks Ben! That was the problem and setting maven.metadata.legacy=true
> solves it.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Migration-to-Maven-3-0-1-Deploy-fails-with-Error-500-only-for-top-most-maven-metadata-xml-tp3332094p3332497.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven 3.0 doesn't download sources

[Yoav Landman]

Hi,

Artifactory 2.3.0+ supports the m3 format for maven-metadata.xml
for snapshot artifacts. But, if you upgraded to 2.3.x and still think there
is something wrong on the Artifactory side, better ask on the Artifactory
user list and we'll be happy to assist you there.

Thanks,

On Wed, Nov 24, 2010 at 8:34 AM, Moser, Christian  wrote:

> I could imagine the culprit could be artifactory. We were forced to update
> from 2.2.2 to 2.2.3, otherwise we weren't be able to deploy with maven 3.0
> (metadata issue in Artifactory 2.2.2, deploy worked only in legacy mode). In
> the meantime just to be sure, we updated to 2.3.1. But were also required to
> change all our repositories to handle "non-unique" snapshots and to deploy
> every snapshot again. It was necessary to use "non-unique" snapshots in
> artifactory because maven was overriding newer locally installed artifacts,
> with older remote artifacts everytime we tried to install a new artifact.
>
> But regarding my two maven user list entries (Maven 3.0 doesn't download
> sources / Maven 3.0 doesn't update snapshot artifacts) it seems there are
> some metadata issues with artifactory & maven 3.0.
>
> So, the right way to go with maven 3.0 is to use repositories with unique
> (timestamped) snapshots artifacts? But this won't work with artifactory at
> least not with version 2.2.3.
>
> -thx Chris
>
> -Ursprüngliche Nachricht-
> Von: Brett Porter [mailto:br...@porterclan.net] Im Auftrag von Brett
> Porter
> Gesendet: Dienstag, 23. November 2010 23:14
> An: Maven Users List
> Betreff: Re: Maven 3.0 doesn't download sources
>
> There's a couple of potential things in the way you've described it:
> - Maven 3.0 does not support non-unique snapshots - you would need to use
> timestamps and rely on the repo manager to purge old versions
> - if I've misunderstood the above, the difference on timestamps is that
> Maven 3.0 will actually store separate metadata per classifier. They should
> be the same in the scenario you describe, but maybe Artifactory doesn't
> support the new metadata format and affects it in some way.
>
> HTH,
> Brett
>
> On 24/11/2010, at 3:21 AM, Stephen Connolly wrote:
>
> > Don't know what it should be but I think we may have found a possible
> > culpret.
> >
> > Check with Benjamin Bentmann, he'd know what m3 is supposed to do
> >
> > -Stephen
> >
> > On 23 November 2010 14:30, Moser, Christian  wrote:
> >
> >> They are from snapshot artifacts. We use non-unique snapshots in
> >> artifactory.
> >> The sources are deployed on the same time like the compiled artifacts.
> So
> >> the timestamp should be equals, shouldn't it?
> >> If not, how could I archieve it?
> >>
> >> -Chris
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> >> Gesendet: Dienstag, 23. November 2010 14:39
> >> An: Maven Users List
> >> Betreff: Re: Maven 3.0 doesn't download sources
> >>
> >> Are these sources of snapshots or releases?
> >>
> >> If snapshots it may be that the sources were deployed with a different
> >> timestamp, in which case the maven metadata my not be letting maven 3
> find
> >> the artifacts.
> >>
> >> IIRC Maven 3 pays more attention to the metadata, whereas Maven 2 might
> not
> >> trust it as much (but I could be wrong, my recollection is fuzzy)
> >>
> >> -Stephen
> >>
> >> On 23 November 2010 12:13, Moser, Christian  wrote:
> >>
> >>> I'm unable to download artifact sources with maven 3.0 and 3.0.1-RC1
> >>> with following command.
> >>>
> >>>
> >>>
> >>> Sources classifier is: -sources (default)
> >>>
> >>>
> >>>
> >>> "mvn -U validate dependency:sources -DoverWriteSnapshots=true
> >>> -DoverWriteReleases=true"
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> the artifacts with classifier -sources are available in the locale
> >>> remote-repository manager (artifactory).
> >>>
> >>>
> >>>
> >>> Is there another call to force maven to download sources?
> >>>
> >>>
> >>>
> >>> Greez Chris
> >>>
> >>>
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
> --
> Brett Porter
> br...@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Yoav

Re: Forbid users to use a certain artifact and/or version

[Yoav Landman]

If you only wish to limit artifact downloads based on path information then
this is already possible to do in Artifactory OSS version by using
include/exclude patterns. If you wish to have more elaborate control then in
Artifactory Pro you can use a custom groovy plugin to veto remote downloads
based on whatever criteria you choose.

HTH,

On Wed, Nov 17, 2010 at 1:49 PM, Asmann, Roland wrote:

> Yes, the customer in this case is a larger company that is starting to
> use Maven, or at least, starting to use it correctly now.
>
>
> On 17.11.2010 12:29, Antonio Petrelli wrote:
> > 2010/11/17 Asmann, Roland :
> >  > I fully agree with you, but as the saying goes 'the customer is
> king'...
> >
> > Just curious, the customer develops too?
> >
> > Antonio
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> --
> Roland Asmann
> Senior Software Engineer
>
> adesso Austria GmbH
> Floridotower 26. Stock  T +43 1 2198790-27
> Floridsdorfer Hauptstr. 1   F +43 1 2198790-927
> A-1210 Wien M +43 664 88657566
>E roland.asm...@adesso.at
>W www.adesso.at
>
> -
> >>> business. people. technology. <<<
> -
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Yoav

Re: Update new release 2.1 plugin to Artifactory?

[Yoav Landman]

You can build the plugin and deploy it as part of the build or you can use
the Artifactory web UI to deploy it. No need to worry about plugins metadata
etc. - Artifactory will recalculate it on the fly.

On Fri, Oct 8, 2010 at 10:21 PM, Wendy Smoak  wrote:

> On Fri, Oct 8, 2010 at 3:24 PM, C. Benson Manica 
> wrote:
>
> > How can I manually deploy the new release plugin version 2.1 to
> Artifactory?
>
> Maybe something to ask on an Artifactory users mailing list?


> In general, you can use "mvn deploy:deploy-file ..." from the command
> line, but you'll need to make sure it gets the metadata right, plugins
> are sensitive to that.  And you may need to deploy other artifacts
> that the plugin depends on.  I'm not sure if Artifactory has a web
> form where you can upload things.
>
> --
> Wendy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Plans to release Maven 3.0

[Yoav Landman]

This may be a result of pom validation checks by Artifactory itself. See:
http://wiki.jfrog.org/confluence/display/RTF/Advanced - suppressing pom
consistency checks. You should see a message in the server log - if you do
try turning it off or deploy a fixed pom version locally.

On Wed, Sep 8, 2010 at 11:31 PM, John Singleton  wrote:

> I have tried to use Maven 3.0 (all beta versions) on our project but the
> build fails due to a metadata error in an artifact in the central
> repository.  The error message is:
>
> Error transferring file: Server returned HTTP response code: 409 for URL:
>
> http://blackbook.jhuapl.edu:8080/artifactory/repo/colt/colt/1.2.0/colt-1.2.0.pom-
> >
> [Help 1]
>
> Is this behavior intended?  (our project builds fine with maven 2.2.1, but
> I
> understand that m3 does more extensive pom verification)
>
> If so, will there be more urgency to fixing bad data in central?  The bad
> colt pom is already identified in MEV-618 (05MAR09) and is still
> unassigned.
>
> Until that happens, what is the recommended fix or workaround?
>
> Thanks,
> John Singleton
>
> On Wed, Sep 8, 2010 at 9:49 AM, Brian Fox  wrote:
>
> > So if you haven't
> > yet, we would like you to grab the latest 3.x build and give us your
> > feedback.
> >
> > --Brian
> > Apache Maven PMC Chair
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: force maven to redownload/refresh "released" dependencies

[Yoav Landman]

You may want to take a look at the CI integration in Artifactory -
http://wiki.jfrog.org/confluence/display/RTF/Build+Integration
You can get a json object with a report of all this information captured at
build time: detailed build environment information, published artifacts and
resolved dependencies of all scopes.
Like many have commented here, re-downloading cached release artifacts if
you run your build from scratch should be done from the caches of your repo
manager.

Yoav

On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed  wrote:

> no, this isn't in regard to our own published artifacts
>
> I regret starting this thread, I apologize
> I didn't mean this question to be an affront to maven conventions - I just
> need to figure out a better way to capture a full log
> they even want a log of how the build environment was downloaded and
> installed
>
>
> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict 
> wrote:
>
> > There is a maxim to follow when deploying: "do not redeploy a version
> more
> > than once". Once you deploy version X.Y.Z, it should never be updated,
> and
> > those who download it never need to download it again. So, back to the
> > original problem, are you guys doing that?
> >
> > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed  wrote:
> >
> > > it only applies to our final release cuts, not our day-to-day
> > > just once for this project really; I wanted to insert such this switch
> > (if
> > > existed) in our "delivery build" profile
> > > we use archiva for everything else, and actually only make use of
> public
> > > maven repositories when we up a version of our dependencies, which is
> > rare
> > > because of change control
> > >
> > > it's all weird stuff, I know, but sometimes I just don't question it
> > >
> > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay  wrote:
> > >
> > > > >> deleting the m2 works, I was just curious to see if there was a
> > switch
> > > > in
> > > > >> maven to force all downloads again
> > > > >
> > > > > This makes absolutely no sense, doesn't change your BOM, and is
> just
> > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is
> > > being
> > > > > used by the whole Maven community.
> > > >
> > > > I'd think that if you had enough developers doing this on every
> > > > machine on a consistent basis (eg every build), it might add up to
> > > > enough traffic to get you on a blacklist somewhere... You really need
> > > > to install Nexus or another MRM, this is just plain dumb.
> > > >
> > > > Wayne
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Custom metadata in a POM?

[Yoav Landman]

Hi,

Using Artifactory you can attach any number of named metadata to a deployed
file (or folder).
This metadata can be either XML or property-based. It is fully searchable
and can be attached and retrieved using simple REST queries (as long as the
end user has the "annotate permission"), so there is no need for
much custom development.
Basically, to add and consume custom metadata to/from a zip you only use to
use simple REST commands to a URL in the form of
http://host:port/path-to-artifact:metadata-name,
which is very lightweight on the repository. You can find more info about
this here: http://www.jfrog.org/confluence/x/CQCq.
The list of named metadata is also available though REST API (
http://www.jfrog.org/confluence/x/C4K5) and since metadata is searchable you
can even use it to manage your artifacts by manipulating search results
found according to metadata queries (promote/move, copy etc.), but that's a
different story :)

Hope that helps,

Yoav
http://www.jfrog.org/

On Sun, Jun 6, 2010 at 9:54 PM, Les Hazlewood  wrote:

> Yep, Nexus would be fantastic for this - we're basically trying to
> come up with the most efficient mechanism to do the following:
>
> 1.  A Grails developer releases a plugin.  This process first entails
> (ideally) Grails uploading it to a Maven repo (i.e. Nexus).
> 2.  Grails (during its 'release-plugin' command) next 'pings' the
> global Grails Plugin Portal (http://www.grails.org/plugin/home) with
> the location of the released artifact(s).
> 3.  The Plugin Portal downloads the plugin metadata when it can based
> on the location specified in #2 and updates its website pages to
> ensure that any searches in the Portal reflect the new release.
>
> The key here is #3 - finding the best way for the Portal to
> most-efficiently download and read in the plugin metadata without
> having to download the entire plugin release.zip.  The Portal has to
> support this for hundreds of plugins every day - it has to be as lean
> as possible.
>
> Best,
>
> Les
>
> On Sun, Jun 6, 2010 at 7:38 AM, Jason van Zyl  wrote:
> > Nexus can utilize anything contained in the repository. Whether a piece
> of metadata exists alongside the artifact or within it, a Nexus plugin could
> be created to process the information. So you don't need to change the way
> Grails plugins are packaged in order to extract the metadata and make it
> available. We know from experience that Nexus is perfect for plugin systems
> :-)
> >
> > On Jun 4, 2010, at 4:28 PM, Les Hazlewood wrote:
> >
> >> Is this possible?  So, in addition to stuff like , is it
> >> possible to add additional metadata?
> >>
> >> I'm asking because the Grails development team is exploring the
> >> possibility of using a Maven repository (e.g. Nexus) to host Grails
> >> plugins.  A Grails plugin is a .zip file, but the Grails environment
> >> (and the global Grails Plugin Portal
> >> http://www.grails.org/plugin/home) need to read Grails-specific
> >> metadata about that .zip without having to download the .zip first.
> >> I'm proposing that the POM could serve that purpose *if* POMs can hold
> >> additional metadata somehow.
> >>
> >> Any ideas?
> >>
> >> Thanks,
> >>
> >> Les
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > -
> >
> >
> >
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Error 502 using mvn deploy

[Yoav Landman]

Do you still run an Apache frontend?

2010/5/15 Benoît Thiébault 

> Yes I did.
> Maybe I just got something wrong with the settings of Apache... I'm not an
> expert in the field and had quite some difficulties with this part
>
> Le 15 mai 2010 à 10:14, Frederic Simon a écrit :
>
> > Out of curiosity: Did you use the embedded jetty with mod_proxy?
> >
> > 2010/5/14 Benoît Thiébault 
> >
> >> I switched from Artifactory to Nexus and it solved the problem...
> >> Thanks for your help
> >>
> >> Le 14 mai 2010 à 16:47, Benoît Thiébault a écrit :
> >>
> >>> The error log says :
> >>> proxy: pass request body failed to host:port from myIP
> >>>
> >>> Le 14 mai 2010 à 16:31, Brian Fox a écrit :
> >>>
>  502 means a timeout between the reverse proxy and the repo manager
> >> behind it.
> 
>  On Fri, May 14, 2010 at 3:33 AM, Benoît Thiébault <
> >> thieba...@artenum.com> wrote:
> > Hi everyone,
> >
> > I have installed a Maven repository and I am trying to deploy my
> >> project on it. My pom generates both the jar and the
> jar-with-dependencies
> >> files. When I use the web interface of the maven repository (its
> Artifactory
> >> in fact), I can upload my jars without any problem.
> >
> > However, when I deploy with Maven using the "mvn deploy" command
> line,
> >> I have a 502 error sent by Apache for the jar-with-dependencies file
> (which
> >> weights 8.2 Mb). As explained here (
> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=44592), it seems
> that
> >> Maven sends the header request, but as it does not send the body just
> >> afterwards, it causes Apache to send the 502 error...
> >
> > Does any of you have already encountered the problem ?
> > I have tried to extend Apache KeepAliveTimeOut value, but it doesn't
> >> seem to work.
> > As a workaround, I was thinking about not deploying the
> >> jar-with-dependencies file automatically, but it does not seem possible
> as
> >> Maven deploys all the articfacts it created...
> >
> > Any help on the subject is welcome :-)
> >
> > Kind regards,
> >
> > Benoit
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> >>>
> >>> 
> >>> Benoît Thiébault
> >>>
> >>> Artenum - Science & Groupware
> >>> http://www.artenum.com
> >>>
> >>> 24, rue Louis-Blanc, 75010 Paris
> >>> tel/fax : +33 (0)1 46 94 67 54
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >>
> >> 
> >> Benoît Thiébault
> >>
> >> Artenum - Science & Groupware
> >> http://www.artenum.com
> >>
> >> 24, rue Louis-Blanc, 75010 Paris
> >> tel/fax : +33 (0)1 46 94 67 54
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Co. Founder and Chief Architect
> > JFrog Ltd
> > http://www.jfrog.org/
> > http://twitter.com/freddy33
>
> 
> Benoît Thiébault
>
>  Artenum - Science & Groupware
>  http://www.artenum.com
>
>  24, rue Louis-Blanc, 75010 Paris
>  tel/fax : +33 (0)1 46 94 67 54
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: I would like to host a mirror of the maven repository. How can I do it?

[Yoav Landman]

Actually,

Artifactory is located at: http://artifactory.jfrog.org (+ live demo:
http://repo.jfrog.org)

I think we'll keep it there for a while ;)

Yoav

On Thu, May 13, 2010 at 11:57 AM, Kalpak Gadre  wrote:

> Do you mean the local mirror or the public mirror?
>
> Anyway there are some open source products available. Look at,
>
> Nexus: http://nexus.sonatype.org/
> Artifactory: http://nexus.sonatype.org/
>
> Thanks,
>
> Kalpak
>
>
>
>  I would like to host a mirror of the maven repository. How can I do it?
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How to add jar file into a Maven 2 environment?

[Yoav Landman]

2010/4/23 Vernon 

>
> Thanks Yoav.
>
> Based on my reading (a quick scanning), JFrog does the same thing as
> Nexus. I will use Nexus for now.
>

Same thing just a lot better :)
Anyway, good luck!


>
>
> 
> > This article is pretty old. You may can follow the new Artifactory
> install
> > instructions here:
> > http://wiki.jfrog.org/confluence/display/RTF/Installing+Artifactory
> > A
> > quick
> > 1 minute setup demo is available here:
> > http://www.youtube.com/watch?v=2FGHwZSAqog
> >
> > HTH,
> >
> > Yoav
> >
> > 2010/4/22 Vernon 
> >
> >> I find an article on the subject:
> >> http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository
> >> .
> >> Does the procedures described in the article good enough for our need?
> >>
> >> 
> >> > Thanks for the information.
> >> >
> >> > How long it will take me to read through the book and set up an
> >> internal
> >> > Maven proxy server?
> >> >
> >> > In a non-Maven environment, we can add those jar files in a minutes.
> >> Of
> >> > course, the downside will be a potential version issues.
> >> >
> >> >
> >> > 
> >> >> Here's a good book on the topic:
> >> >> http://www.sonatype.com/books/nexus-book/reference/
> >> >>
> >> >> 2010/4/22 Vernon :
> >> >>> Thanks a lot for your information.
> >> >>>
> >> >>> Where I can find a documentation on the subject (an internal Maven
> >> >>> proxy
> >> >>> server)? I have a look at the maven documentation under the user
> >> center
> >> >>> and haven't find any useful information yet.
> >> >>>
> >> >>>
> >> >>> 
> >>  Right if its not in a public Maven repository you have to add it to
> >>  yours.  Ideally you will have an internal Maven proxy server such
> >> as
> >>  Artifactory/Nexus where you can deploy it once and all can get it
> >> from
> >>  there.
> >> 
> >>  (Regarding iText 5.x the reason that's not in a public maven is the
> >>  license has changed greatly starting with this version.)
> >> 
> >>  -Dave
> >> 
> >>  2010/4/20 Vernon :
> >> >
> >> > We need to add PayPal Java library files into our Maven
> >> development
> >> > environment. PayPal doesn't make any Maven artifact ID. What is a
> >> > right
> >> > way of adding a jar file?
> >> >
> >> > And one more related question: shall we add jar file by ourselves
> >> for
> >> > a
> >> > new version of jar file? For example, the current version of iText
> >> is
> >> > 5.0.x and the highest version with Maven artifact ID is 2.7.x.
> >> >
> >> > Thanks very much in advance.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> -
> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> >
> >> >
> >> 
> >> 
> -
> >>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>  For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> >> 
> >>  
> >>  Spam/Virus scanning by CanIt Pro
> >> 
> >>  For more information see
> >>  http://www.kgbinternet.com/SpamFilter.htm
> >> 
> >>  To control your spam filter, log in at
> >>  http://filter.kgbinternet.com
> >> 
> >> >>>
> >> >>>
> >> >>> --
> >> >>> 蒲公苁  http://www.pu-gong-ying.info -
> >> 您的社区信息服务网站
> >> >>>
> >> >>> 新闻门户 -
> >> >>> 容易、快速地浏览来自世界各地主要新闻机构的超迁 0个新闻条目ã€
> >> >>> 社会新闻 - 与他人分享您的故事ã€
> >> >>> 服务指南 -
> 寻找或评论的吃喝、购物ã€�游玩地方ã€
> >> >>> 分类广告 - 张贴和浏览当地的分类广告、
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> -
> >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> >>
> >> >>
> >> >> 
> >> >> Spam/Virus scanning by CanIt Pro
> >> >>
> >> >> For more information see
> >> >> http://www.kgbinternet.com/SpamFilter.htm
> >> >>
> >> >> To control your spam filter, log in at
> >> >> http://filter.kgbinternet.com
> >> >>
> >> >
> >> >
> >> > --
> >> > 蒲公苁  http://www.pu-gong-ying.info -
> >> 您的社区信息服务网站
> >> >
> >> > 新闻门户 -
> >> 容易、快速地浏览来自世界各地主要新闻机构的超迁 0个新闻条目ã€
> >> > 社会新闻 - 与他人分享您的故事ã€
> >> > 服务指南 -
> 寻找或评论的吃喝、购物ã€�游玩地方ã€
> >> > 分类广告 - 张贴和浏览当地的分类广告、
> >> >
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: users-

Re: How to add jar file into a Maven 2 environment?

[Yoav Landman]

This article is pretty old. You may can follow the new Artifactory install
instructions here:
http://wiki.jfrog.org/confluence/display/RTF/Installing+Artifactory
A quick
1 minute setup demo is available here:
http://www.youtube.com/watch?v=2FGHwZSAqog

HTH,

Yoav

2010/4/22 Vernon 

> I find an article on the subject:
> http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository .
> Does the procedures described in the article good enough for our need?
>
> 
> > Thanks for the information.
> >
> > How long it will take me to read through the book and set up an internal
> > Maven proxy server?
> >
> > In a non-Maven environment, we can add those jar files in a minutes. Of
> > course, the downside will be a potential version issues.
> >
> >
> > 
> >> Here's a good book on the topic:
> >> http://www.sonatype.com/books/nexus-book/reference/
> >>
> >> 2010/4/22 Vernon :
> >>> Thanks a lot for your information.
> >>>
> >>> Where I can find a documentation on the subject (an internal Maven
> >>> proxy
> >>> server)? I have a look at the maven documentation under the user center
> >>> and haven't find any useful information yet.
> >>>
> >>>
> >>> 
>  Right if its not in a public Maven repository you have to add it to
>  yours.  Ideally you will have an internal Maven proxy server such as
>  Artifactory/Nexus where you can deploy it once and all can get it from
>  there.
> 
>  (Regarding iText 5.x the reason that's not in a public maven is the
>  license has changed greatly starting with this version.)
> 
>  -Dave
> 
>  2010/4/20 Vernon :
> >
> > We need to add PayPal Java library files into our Maven development
> > environment. PayPal doesn't make any Maven artifact ID. What is a
> > right
> > way of adding a jar file?
> >
> > And one more related question: shall we add jar file by ourselves for
> > a
> > new version of jar file? For example, the current version of iText is
> > 5.0.x and the highest version with Maven artifact ID is 2.7.x.
> >
> > Thanks very much in advance.
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
>  
>  Spam/Virus scanning by CanIt Pro
> 
>  For more information see
>  http://www.kgbinternet.com/SpamFilter.htm
> 
>  To control your spam filter, log in at
>  http://filter.kgbinternet.com
> 
> >>>
> >>>
> >>> --
> >>> 蒲公英 http://www.pu-gong-ying.info - 您的社区信息服务网站
> >>>
> >>> 新闻门户 -
> >>> 容易、快速地浏览来自世界各地主要新闻机构的超过4000个新闻条目。
> >>> 社会新闻 - 与他人分享您的故事。
> >>> 服务指南 - 寻找或评论的吃喝、购物、游玩地方。
> >>> 分类广告 - 张贴和浏览当地的分类广告。
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >> 
> >> Spam/Virus scanning by CanIt Pro
> >>
> >> For more information see
> >> http://www.kgbinternet.com/SpamFilter.htm
> >>
> >> To control your spam filter, log in at
> >> http://filter.kgbinternet.com
> >>
> >
> >
> > --
> > 蒲公英 http://www.pu-gong-ying.info - 您的社区信息服务网站
> >
> > 新闻门户 - 容易、快速地浏览来自世界各地主要新闻机构的超过4000个新闻条目。
> > 社会新闻 - 与他人分享您的故事。
> > 服务指南 - 寻找或评论的吃喝、购物、游玩地方。
> > 分类广告 - 张贴和浏览当地的分类广告。
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> > 
> > Spam/Virus scanning by CanIt Pro
> >
> > For more information see
> > http://www.kgbinternet.com/SpamFilter.htm
> >
> > To control your spam filter, log in at
> > http://filter.kgbinternet.com
> >
>
>
> --
> 蒲公英 http://www.pu-gong-ying.info - 您的社区信息服务网站
>
> 新闻门户 - 容易、快速地浏览来自世界各地主要新闻机构的超过4000个新闻条目。
> 社会新闻 - 与他人分享您的故事。
> 服务指南 - 寻找或评论的吃喝、购物、游玩地方。
> 分类广告 - 张贴和浏览当地的分类广告。
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven and Hudson

[Yoav Landman]

You may be interested to also look at the specific Hudson integration of
Artifactory for full build traceability. This is coming very soon to
TeamCity as well:
http://wiki.jfrog.org/confluence/display/RTF/Build+Integration

On Wed, Apr 7, 2010 at 9:26 PM, Lorenzo Thurman wrote:

> Ok, thanks. Two more things to look at now, TeamCity and Artifactory.
> On Apr 7, 2010, at 1:20 PM, David Hoffer wrote:
>
> > The tool stack we use is SVN, Maven, TeamCity & Artifactory.
>
> "There are 10 types of people in this world: those who understand binary,
> those who don't"
> --Unknown
>
> Lorenzo Thurman
> lore...@thethurmans.com
>
>
>

Re: verifying artifact on deployment

[Yoav Landman]

Artifactory 2.2.2 (the upcoming minor release) already has configurable
checksum verification for _uploaded_ artifacts too.

FYI.

On Thu, Feb 25, 2010 at 5:02 PM, Marc Lustig  wrote:

> thanks for the swift response.
> First I also thought it's an Archiva issue, but basically Maven is talking
> to the Repo Manager, right? So Maven defines the contract, and Archiva can
> only respond to the contract.
>
> We are still investigating the issue and try to reproduce different
> scenarios.
>
> For now, the question for us is whether Maven has the concept of
> artifact-verification by using hash-codes at all.
> Any input on this matter?
>
>
>
> 2010/2/25 Brett Porter 
>
> >
> > On 26/02/2010, at 1:30 AM, Wendy Smoak wrote:
> >
> > > On Thu, Feb 25, 2010 at 8:10 AM, Marc Lustig 
> wrote:
> > >> we had a number of cases when the artifact in our central-repo
> > >> (Archiva-based) was not consistent with the corresponding hash.
> > >
> > > You can configure the checksum policy to fail when Maven _downloads_
> > > an artifact if the checksum doesn't match.
> > >
> > > If you're having trouble with checksums when deploying to Archiva, it
> > > would probably be best to ask on the Archiva users list.  If artifacts
> > > are getting added with the wrong checksum, that's probably a bug.
> >
> > Could it be one of these?
> > http://jira.codehaus.org/browse/MNG-4301
> > http://jira.codehaus.org/browse/MNG-4235
> >
> > > It
> > > does have some 'repository health' reports that might help find the
> > > problems after the fact.
> >
> >
> > - Brett
> >
> > --
> > Brett Porter
> > br...@apache.org
> > http://brettporter.wordpress.com/
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: How do I prevent maven from searching my own artifacts in public repositories ?

[Yoav Landman]

Yes, Artifactory supports filtering with include/exclude patterns for both
proxied and hosted repositories.

On Fri, Nov 20, 2009 at 12:55 PM, Anders Hammar  wrote:

> I think that the battle today is between Nexus and Artifactory. Archiva has
> a few features that Nexus for instance lacks, but the development of
> Archiva
> is slower than Nexus for instance.
> Regarding Nexus or Artifactory you should which one fits your needs the
> best. Nexus supports the "filtering" you're talking about below (it's
> called
> routing rules in Nexus). Not sure about Artifactory.
>
> /Anders
>
> On Fri, Nov 20, 2009 at 09:03, TorstenKarusseit  >wrote:
>
> > Hi all,
> >
> > thank you very mutch.
> > I think Anders is right saying to use a repo manager,
> > wich has to filter the artifact request if it matchs a
> > predefined pattern of my project.
> >
> > Do anyone of you have experience with such a manager ?
> > Nexus or Archiva ?
> >
> > Torsten
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: How to fix the java.net repository relocation

[Yoav Landman]

When using Artifactory this scenario can be circumvented, as we never let
bad poms pass through, so you won't end up with html pages in your
repository when a remote repository is broken.

On Thu, Nov 12, 2009 at 11:53 AM, Lahiru Gunathilake wrote:

> Hi Stephan,
>
> Actually this is not about building the products in my machine, we are
> suppose to host our source packs and let users to download it and build it
> in their machines. So a the build should go smoothly and should not stuck
> due to relocation of java.net repository.
>
> Let me explain the situation, before that I would say this is a kind of a
> bug in maven, simply because maven does not skip taking an artifact if one
> of the maven repo sends a 301(MOVED PERMANANTLY) and it simply take that
> message and write it as the pom file. Simply if the maven repo sends 404 it
> skip that repo and go for another, but here with 301 it just dump the
> message as the pom file and later on this failes.
>
> In our build system we are not refering this java.net repository in any
> location but maven itself go for the java.net repo, so please be kind
> enough
> to help to fix this.
>
> I have only one solution for the time being, which is configuring
> java.netrepository not to send 301 and send 404. I can simply patch
> the maven, to
> handle this scenario but we are stuck with our release process due to this
> issue since our products are open source.
>
> Lahiru
>
> On Thu, Nov 12, 2009 at 2:10 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Use a repository manager and have it proxy everything.  that way you can
> > just to mirrorOf>*< in your settings.xml. It will merge all repositories
> and
> > everything just works(TM)
> >
> >
> > 2009/11/12 Lahiru Gunathilake 
> >
> >> Hi Stephen,
> >>
> >> I tried with a clean repo, but didn't worked for me. I have encountered
> >> this repository failures time to time. So we have our own repository
> where
> >> we host our artifacts. Now I want to add all these third party artifacts
> I
> >> used to build the product stack to our own repository. Is this possible
> to
> >> do and do the build products by adding our repository in to the pom.xml
> of
> >> Apache projects we are building.
> >>
> >> Can you please tell me how to host those third party artifacts in to our
> >> own repository.
> >>
> >> Lahiru
> >>
> >>
> >> On Thu, Nov 12, 2009 at 1:58 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> 2009/11/12 Lahiru Gunathilake 
> >>>
>  Hi Stephen,
> 
> 
>  On Thu, Nov 12, 2009 at 12:10 PM, Stephen Connolly <
>  stephen.alan.conno...@gmail.com> wrote:
> 
> > AFAIK,
> >
> > Axis2 is an apache project and would be deploying to repo1.maven.org
> .
> > The rules for repo1.maven.org are that you cannot rely on any
> > artifacts which are not hosted on repo1.maven.org.
> >
>  I think there were artifacts hosted and now it's moved.
> 
>  repo1.maven.org is write-once
> >>>
> >>> artifacts cannot be removed from repo1.maven.org
> >>>
> >>>
>   As such, I would expect that Axis2 _should not_ require artifacts
> from
> > java.net, and should not have any  sections in their
> > pom.xml files.
> 
>  Yes axis2 doesn't have any repository section in it's pom files but
> when
>  I manually add the relocated repo in to the Axis2 pom it successfully
> get
>  some of the artifacts and later on it again refer to the wrong
> location and
>  get a html content in the the pom file. please refer the error
> here[1].
> 
> >>>
> >>> sounds like your local repository is corrupted.  blow away
> >>> ~/m2/repository/org/apache (or move it to a temporary location)
> >>>
> >>>
>   (OK technically they are allowed ones which are only
> > enabled for -SNAPSHOTs... but it cannot be enabled for releases)
> >
> > That is the theory, now it may well be that Axis2 is being bold and
> > depending on java.net.
> >
> > To answer your question.  Your best bet is to set up a maven
> > repository manager (e.g. nexus, artifactory, etc) and configure your
> > settings.xml to use that repository manager as *
> >
>  I will try for this and get back to you.
> 
> 
>  [1]http://www.pastie.org/694974
>  Thanks in advance
>  Lahiru
> 
> >
> > Then you can add all the repositories you want to source artifacts
> > from to your repository manager, and you should be able to build.
> >
> > Also this sounds more like a question for the Axis2 list
> >
> > -Stephen
> >
> > 2009/11/12 Lahiru Gunathilake :
> > > Hi all,
> > >
> > > I am trying to build set stack of java products which fails due to
> > the
> > > relocation of
> > https://maven-repository.dev.java.net/nonav/repository/. From
> > > the product stack I am buiding Apache Axis2 very first and I cannot
> > see this
> > > rep

Re: speedier builds possible?

[Yoav Landman]

And with Artifactory you can save more download time by enabling eager
parallel fetching of jars when a pom is requested and -sources when a jar is
requested.

On Wed, Aug 12, 2009 at 9:45 PM, Brian Fox  wrote:

> If you aren't using a repository manager, then using one can save a
> good chunk of time.
>
> On Wed, Aug 12, 2009 at 1:45 PM, Jonathan
> Woods wrote:
> > Couple of simple ideas: not 'clean'ing unless you need to; and skipping
> > tests when it's safe to do so:
> >
> > mvn Dmaven.test.skip=true (or -DskipTests=true)
> >
> >> -Original Message-
> >> From: Roger Pack [mailto:rogerdpa...@gmail.com]
> >> Sent: 12 August 2009 18:17
> >> To: users@maven.apache.org
> >> Subject: speedier builds possible?
> >>
> >> Hi. I was wondering if there are any industry standard ways
> >> of speeding up a maven build, like in a project with a single
> >> parent and multiple children modules
> >>
> >> "only building dependencies that have changed since the last
> >> svn commit"
> >> or
> >> "building things in parallel where possible"
> >> Or anything else.
> >> Anybody know of much on that topic?
> >> Thanks!
> >> -r
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: can't access snapshots

[Yoav Landman]

Please follow the instructions at
http://wiki.jfrog.org/confluence/display/RTF/Configuring+Artifacts+Resolutionand
you'll be fine.
Mirror-any by itself without a repository definition is not enough for
overriding snapshot resolution.

Yoav

On Fri, Apr 17, 2009 at 2:56 PM, Rüdiger Gubler  wrote:

>
> Hi,
>
> I can't access snapshots in my artifactory.
>
> The jat is deployed with mvn deploy
> ...
> Uploading:
>
> http://pc489:80/artifactory/libs-local/com/initka/bprocess/gisinterface/0.0.1-SNAPSHOT/gisinterface-0.0.1-20090417.113758-2.jar
> ...
>
> in an other module i have the following entry
>
>
>  com.initka.bprocess
>  gisinterface
>  0.0.1-SNAPSHOT
>
>
> If my local repository is empty i get the following error
>
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
>
> Missing:
> --
> 1) com.initka.bprocess:gisinterface:jar:0.0.1-SNAPSHOT
>
>  Try downloading the file manually from the project website.
>
>  Then, install it using the command:
>  mvn install:install-file -DgroupId=com.initka.bprocess
> -DartifactId=gisinterface -Dversion=0.0.1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
>
>  Alternatively, if you host your own repository you can deploy the file
> there:
>  mvn deploy:deploy-file -DgroupId=com.initka.bprocess
> -DartifactId=gisinterface -Dversion=0.0.1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
>  Path to dependency:
>1) com.initka.bprocess:giskernel:jar:0.0.1
>2) com.initka.bprocess:gisinterface:jar:0.0.1-SNAPSHOT
>
>
> My settings contains
>
>  
>
>  artifactory
>  *
>  http://pc489/artifactory/repo
>  artifactory
>
>  
>
>
> The libs-local repository is configured to handle releases and snapshots.
> I also tried separate repositories for releases and snapshots.
> If I deploy a release of the jar it is found.
>
> What is going wrong?
>
>
> --
> View this message in context:
> http://www.nabble.com/can%27t-access-snapshots-tp23096088p23096088.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: dependency lookup url

[Yoav Landman]

Please see:
http://wiki.jfrog.org/confluence/display/RTF/Configuring+Artifacts+Resolution

On Wed, Mar 11, 2009 at 10:25 PM, mcystems  wrote:

> I tried every possible combination on settings.xml: without mirrors,
> with mirrors defining snapshot a release repositories remove them.
> Nothing. It seems that the build-in central repository configuration
> cannot be override in settings.xml. While I debugged maven I find that
> the "central" repository policy is always disabled no matter what.
>
> However! If I put my snapshot repository url into the projects pom.xml
> it works.
>
> Csaba
>
> On Tue, 2009-03-10 at 16:29 -0700, Wayne Fay wrote:
> > > I'm mirroring everything to my artifactory instance (maybe that is
> > > misconfigured/bugy but since I don't know the lookup url I can't figure
> > > out).
> >
> > You still need to declare a snapshot-enabled repo somewhere in your
> > settings.xml.
> >
> > Wayne
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Mirror-any setup doesn't work with snapshots

[Yoav Landman]

Hi,

Did you experience a different behavior with 2.0.9?
Can you try explicitly overriding central and snapshots ("classic setup" -
http://wiki.jfrog.org/confluence/display/RTF/Configuring+Artifacts+Resolution
).

Yoav

On Fri, Feb 20, 2009 at 11:05 AM, Olivier THIERRY  wrote:

> Hi,
>
> I try to user mirror-any setup with Maven 2.0.10 and Artifactory 2.0.2
> but it doesn't work with snapshots. Any time I have a dependency to a
> snapshot artifact in a POM file, it fails at resolving it.
>
> For example :
>
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
>
> GroupId: org.andromda.maven.plugins
> ArtifactId: andromdapp-maven-plugin
> Version: 3.4-SNAPSHOT
>
> Reason: Unable to download the artifact from any repository
>
>  org.andromda.maven.plugins:andromdapp-maven-plugin:pom:3.4-SNAPSHOT
>
> from the specified remote repositories:
>  artifactory (http://intrabe:8080/artifactory/repo)
>
> But I can see this artifact using Artifactory web client, so it exists !
>
> I configured mirror-any this way in Maven settings.xml file :
>
>
>  artifactory
>  *
>  Horoquartz Repository
>  http://intrabe:8080/artifactory/repo
>
>
> I see nothing in Artifactory logs, so it looks like no request is sent
> to Artifactory.
>
> Anyone has an idea what I did wrong ?
>
> Regards,
>
> Olivier
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Deploy on shared internal repository

[Yoav Landman]

Hi,

Looks like you are failing on the different repo id/same repo url issue
(see:
http://wiki.jfrog.org/confluence/display/RTF/Configuring+Artifacts+Resolution,
bottom of the page). The corresponding server output would provide more
info.
Anyway, it's better to ask artifactory-specific questions on
artifactory-users (http://www.nabble.com/Artifactory-Users-f19964.html).

Thanks,

Yoav

2009/2/16 Jan Chodura 

> Hi,
>
> can you help me what's wrong with my configuration for deploying app to
> JFrog artifactory?
>
> On jfrog artifactory I have repository myAppsRepository.
> I use eclipse 3.4 (but on the command line it's the same problem), maven
> 2.0.9
>
> settings.xml
> 
>  
>   
> myRemoteRepository
> user
> password
> 
>   
> 
>
> pom.xml contains
> 
>   
>   iBbRepository
>   
>   http://somewhere:8081/artifactory/myAppsRepository
>   
>   
>   
>
> and
>
>   
>   
>   myRemoteRepository
>   Rapper
>   http://somewhere:8081/artifactory/myAppsRepository
>   
>  
>
> And there is stacktrace:
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' -->
> [DEBUG]   (f) artifact = cz.billboard:myApp:war:0.0.1
> [DEBUG]   (f) attachedArtifacts = []
> [DEBUG]   (f) deploymentRepository = [myRemoteRepository] ->
> http://somewhere:8081/artifactory/myAppsRepository
> [DEBUG]   (s) localRepository = [local] -> file://C:\Documents and
> Settings\jach\.m2\repository
> [DEBUG]   (f) packaging = war
> [DEBUG]   (f) pomFile = C:\data\eclipse\projects\Application\pom.xml
> [DEBUG]   (f) skip = false
> [DEBUG]   (f) updateReleaseInfo = false
> [DEBUG] -- end configuration --
> [INFO] [deploy:deploy]
> Uploading:
> http://somewhere:8081/artifactory/myAppsRepository/cz/billboard//myApp/0.0.1/myApp-0.0.1.war
> 31394K uploaded
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Error deploying artifact: Error transferring file
>
> Error writing to server
> [INFO]
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
> artifact: Error transferring file
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying
> artifact: Error transferring file
>   at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:195)
>   at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
>   ... 16 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Error deploying artifact: Error transferring file
>   at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:94)
>   at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173)
>   ... 18 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Error
> transferring file
>   at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(LightweightHttpWagon.java:178)
>   at
> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:244)
>   at
> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:160)
>   at
> org.apache.maven

[ANN] Artifactory 2.0 has been released!

[Yoav Landman]

We are pleased to announce the availability of Artifactory 2.0.

After 6 months of development, over 400 resolved issues, out of which 170
are new features and over 450 integration tests, the second major release of
Artifactory is out with 100% UI-based configuration and new great features:

- Built-in UI configurable and UI-testable LDAP integration (other
integrations possible via Spring Security).
- No more clear text passwords in your Maven settings.xml - Artifactory
offers auto-generated encrypted passwords, which is extremely important when
using external authentication.
- Ability to undeploy complete versions and remove in one go hundreds of old
artifacts deployed from the same module.
- Sophisticated role-based access control (RBAC), e.g - you can allow only
certain groups to see sources.
- Security domain level administrators.
- Real time view for the effective RBAC on a selected artifact/node.
- Ability to deploy a bundle of zipped artifacts and import a Maven local
repository into Artifactory.
- True undeploy with immediate Maven metadata updates.
- Real time tailing of server logs from the UI.
- Remote checksum validations.
- Built-in support for MySql.
- Tomcat install script has been Improved and the ability to run as a
Windows Service.
- Special support to run under IBM WebSphere.
- An artadmin command-line tool for performing various administrative tasks.
- The underlying architecture to support high volumes of concurrent
downloads and uploads have been updated.
- Help on nearly every UI element.
- Improved, complete user guide.

Artifactory is available for immediate download from the JFrog Site (
http://www.jfrog.org) or directly from SourceForge at
http://sourceforge.net/project/platformdownload.php?group_id=175347.

The detailed release information is available from JIRA here:
http://issues.jfrog.org/jira/browse/RTFACT/fixforversion/10290

The Artifactory User Guide can be found here:
http://wiki.jfrog.org/confluence/display/RTF/Artifactory+User+Guide.

You can also welcome to give the Online Demo a try at http://repo.jfrog.org.

Enjoy!

The JFrog Artifactory Team
http://artifactory.jfrog.org

Re: Failed to Resolve Artifact Error

[Yoav Landman]

Can you request the file directly via wget or a browser?

http://host:port
/artifactory/repo/commons-digester/commons-digester/2.0/commons-digester-2.0.jar

On Mon, Jan 5, 2009 at 11:27 PM, jpalmer1026  wrote:

>
> The project I'm working on has a transitive dependency to the
> commons-digester 2.0 jar file. When the pom is run, we get the following
> error.
>
> [INFO] Failed to resolve artifact.
> [14:08:01]: Missing:
> [14:08:01]: --
> [14:08:01]: 1) commons-digester:commons-digester:jar:2.0
>
> We've tried copying the file to the repo manually and we still get the
> error. Does anyone have  any suggestions?
> --
> View this message in context:
> http://www.nabble.com/Failed-to-Resolve-Artifact-Error-tp21299201p21299201.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: possibility to control an artifact version when installing/deploying/releasing?

[Yoav Landman]

konkere wrote:
> 
> 
> matinh wrote:
>> 
>> Archiva has an open issue for it:
>> https://jira.codehaus.org/browse/MRM-747
>> 
> 
> i know very well how long it takes in opensource projects ;). i've seen
> this issue, but i need already implemented and tested solution, as this
> feature is one of the main requirements (and besides we are politically
> discouraged to used things like webdav, so that's not an option anyway).
> 
> 
> Yoav  Landman wrote:
>> 
>> Artifactory 1.3.0 has this feature (redeploying/overriding the same
>> artifact version is controlled by the "delete" permission).
>> 
> 
> not documented - not existing :D. ok i'll also try atrifactory. is 1.3.0
> fully migrated to Spring Security? i also need LDAP integration (and from
> what i saw here: http://www.nabble.com/LDAP-Integration-td17763888.html it
> hasn't been the case yet).
> 

True. We are updating the 1.3 docs towards the final release in a couple of
days :)
And yes, full LDAP/AD integration is already there for quite some time in
1.3 with full UI configuration. You are welcome to give it a go.


konkere wrote:
> 
> 
> Brian E Fox wrote:
>> 
>> You can see the comparison matrix here:
>> http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
>> 
> 
> oh thanks, that's a good one.
> 

-- 
View this message in context: 
http://www.nabble.com/possibility-to-control-an-artifact-version-when-installing-deploying-releasing--tp21119401p21133964.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: possibility to control an artifact version when installing/deploying/releasing?

[Yoav Landman]

Artifactory 1.3.0 has this feature (redeploying/overriding the same artifact
version is controlled by the "delete" permission).


konkere wrote:
> 
> thanks, guys!
> 
> so which manager would you suggest? i read a bit about nexus, archiva and
> artifactory on the very feature of prohibiting redeploy. nexus does it for
> sure (though role-based), while the other two seem not to handle this (and
> that is my question - is it really?).
> 

-- 
View this message in context: 
http://www.nabble.com/possibility-to-control-an-artifact-version-when-installing-deploying-releasing--tp21119401p21126129.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [Artifactory-users] Artifactory 1.3 has been DOS'ing the Central repository

[Yoav Landman]

Brian,

I think it is only a reasonable expectation from you, to contact our team
immediately as soon as you found out about this bug, so that we can let our
users know how to work around it and if they are affected at all. However,
since you are the Nexus commercial project manager, we are concerned that
the way you chose to handle this is not coming purely of sincere concern for
the Maven community.

This issue is only with the 1.3.0 *betas* (up to beta-6) and has 2 simple
workarounds: Use an invalid CRON value or exclude repo1 from periodic index
downloads.
In any case, Artifactory will download the index on demand, which will use a
HEAD request first to test for unmodified index (sadly repo1 does not like
conditional GETs).

We will easily fix this issue in the upcoming release.

To disable the indexer cron set in the UI or in artifactory.config.xml file:

invalid

And you should see in your log:
[ERROR] (o.a.r.index.
IndexerManagerImpl:72) Bad indexer cron expression 'invalid' will be ignored
(Illegal characters for this position: 'INV').

To remove repo1 from periodic index downloads:

0 0 /1 * * *

repo1



Happy Thanksgiving,

Yoav Landman
The Artifactory Team


On Fri, Nov 28, 2008 at 2:50 PM, Brian E. Fox <[EMAIL PROTECTED]>wrote:

>  Since approximately Mid August, the load on Central has been growing at
> an exponential rate. You may have noticed slowdowns or dropped connections
> recently as a side effect. We first had issues with Apache HTTPD load
> increasing above the capacity of the machine. We switched over to Nginx (
> http://blogs.sonatype.com/people/brian/2008/10/29/nginx-is-centrals-new-friend/)
> and this resolved the load, but then the 100mbps connection was regularly
> becoming saturated. Every hour, on the hour for about 20 minutes around the
> clock, the connection would max out and then return to about 50%
> utilization. We spent many days working with Contegix to diagnose the
> problem but no single source stood out immediately.
>
>
>
> Yesterday we finally discovered that nearly all the traffic, both the
> hourly spikes and the 50% background traffic is being caused by downloads of
> the nexus-index.zip. After investigating the various tools that use this
> data, we have concluded that Artifactory has a critical bug ( apparently
> since June: http://issues.jfrog.org/jira/browse/RTFACT-390) that is
> causing every 1.3 instance to repeatedly download the 27mb zip file. We
> found many cases of a single ip downloading the index more than 1000 times a
> day! In the config it is set as follows:
>
>
>
> 
>
> 
>
> 
>
> 0 0 /5 * * ?
>
> 
>
>
>
> (this is a quartz syntax which is "s m h…")
>
>
>
> This by itself wouldn't be a huge issue except for the fact that
> Artifactory ignores the index.properties file which contains the last update
> timestamp AND doesn't first issue a HEAD to check the timestamp. This means
> that every Artifactory 1.3 instance is grabbing this 27mb file at least
> every 5 hours (we can't explain why certain ips are doing it 1000+ times a
> day..perhaps the config was modified there or some other scheduling issue is
> present).
>
>
>
> For reference, the index on central is only updated once a week on Sundays.
>
>
>
>
> To protect the Maven Community from ongoing troubles, we have had to take
> the extra-ordinary step of blocking all downloads of the index file by
> Artifactory until this is resolved. Upon doing this, the traffic has fallen
> to 10% of what it has been in the recent past. If you are using Artifactory,
> please adjust this cron definition to run only weekly and save yourself and
> us tons of wasted bandwidth and money.
>
>
>
> Note that other tools like the Nexus Maven Repository Manager (
> http://nexus.sonatype.org), M2e and Q4e use the Nexus Indexer API and are
> immune to this problem and are not blocked from downloading the index. A new
> version of Nexus and the Nexus Indexer API will be published soon along with
> M2e that will leverage incremental indexes to significantly reduce the
> download requirements and allow near real time index updates.
>
>
>
> Brian Fox
>
> Apache Maven PMC
>
> http://blogs.sonatype.org/people/brian
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Artifactory-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/artifactory-users
>
>

Re: Is anybody use Jfog Artifactory as their company-level repository?

[Yoav Landman]

This is an old known issue on Jetty/Redhat that is long resolved since
version 1.2.5u1 and of course in the 1.3.0 betas. It is also real easy to
fix by manually creating the work folder for Jetty.
No need to cross-post, BTW.

Yoav


陈思淼 wrote:
> 
> there is a Bug about Artifactory combine jetty, it's will lost its works
> dircectory every one or two weeks ,because jetty put the works directory
> in
> the /tmp.
> So we must restart our artfactory.sh every one or two weeks.
> yestoday after we use killall -9 java to kill jetty process and restart
> it.
> there is a exception:
> 
>> java.lang.RuntimeException: Failed to config jcr repo.
>>
> at org.artifactory.jcr.JcrHelper.(JcrHelper.java:112)
> 
> at
> org.artifactory.config.CentralConfig.afterPropertiesSet(CentralConfig.java:158)
> 
> at
> org.artifactory.config.CentralConfigFactoryBean.afterPropertiesSet(CentralConfigFactoryBean.java:69)
> 
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCap
> 
> ableBeanFactory.java:1202)
> 
> I guess that's becouse the killall cause some JCR problem in artifactory.
> Can anybody tell me how to stop the process politely install of killall -9
> ?
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Is-anybody-use-Jfog-Artifactory-as-their-company-level-repository--tp19699271p19700108.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Missing: org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.2.4

[Yoav Landman]

Sure, just add http://repo.jfrog.org/artifactory/plugins-releases-local to
your list of repositories (you can also use the virtual repo url
http://repo.jfrog.org/artifactory/repo to search in all jfrog's hosted
repositories).

Yoav


thomas2004 wrote:
> 
> Hi,
> 
> Surely I can download the jar file first and then install it manually. But
> I don't like in such a way so much.
> 
> Can I do it automatically?
> 
> Regards
> 
> Thomas
> 
> 
> 
> Yoav  Landman wrote:
>> 
>> Yes, we installed a newer version of Artifactory over the weekend. Should
>> be alright now and
>> your artifact is available at
>> http://repo.jfrog.org/artifactory/plugins-releases-local/org/jfrog/maven/annomojo/maven-plugin-anno/1.2.4/maven-plugin-anno-1.2.4.jar
>> 
>> Yoav
>> 
>> 
>> matinh wrote:
>>> 
>>> On Friday 29 August 2008 thomas2004 wrote:
>>>> Hi all,
>>>>
>>>> As I try to build the project by "mvn eclipse:eclipse" I got error as
>>>> follow:
>>>>
>>>> [code]
>>>> [ERROR] BUILD ERROR
>>>> [INFO]
>>>> 
>>>> [INFO] Failed to resolve artifact.
>>>>
>>>> Missing:
>>>> --
>>>> 1) org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.2.4
>>> 
>>> You get this because the maven-plugin-anno is not in maven's central 
>>> repository. According to [0] your can configure maven to use JFrog's 
>>> repository which would be the best option. Unfortunately this repo seems
>>> to 
>>> be broken at the moment.
>>> 
>>> As an alternative you can download the ZIP file as also explained on the 
>>> page mentioned above [0] and extract it into your local repository 
>>> (~/.m2/repository on unix).
>>> 
>>> hth,
>>> - martin
>>> 
>>> [0] http://www.jfrog.org/sites/mvn-anno-mojo/latest/
>>> 
>>>  
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Missing%3A-org.jfrog.maven.annomojo%3Amaven-plugin-anno%3Ajar%3A1.2.4-tp19217580p19250189.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Missing: org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.2.4

[Yoav Landman]

Yes, we installed a newer version of Artifactory over the weekend. Should be
alright now and
your artifact is available at
http://repo.jfrog.org/artifactory/plugins-releases-local/org/jfrog/maven/annomojo/maven-plugin-anno/1.2.4/maven-plugin-anno-1.2.4.jar

Yoav


matinh wrote:
> 
> On Friday 29 August 2008 thomas2004 wrote:
>> Hi all,
>>
>> As I try to build the project by "mvn eclipse:eclipse" I got error as
>> follow:
>>
>> [code]
>> [ERROR] BUILD ERROR
>> [INFO]
>> 
>> [INFO] Failed to resolve artifact.
>>
>> Missing:
>> --
>> 1) org.jfrog.maven.annomojo:maven-plugin-anno:jar:1.2.4
> 
> You get this because the maven-plugin-anno is not in maven's central 
> repository. According to [0] your can configure maven to use JFrog's 
> repository which would be the best option. Unfortunately this repo seems
> to 
> be broken at the moment.
> 
> As an alternative you can download the ZIP file as also explained on the 
> page mentioned above [0] and extract it into your local repository 
> (~/.m2/repository on unix).
> 
> hth,
> - martin
> 
> [0] http://www.jfrog.org/sites/mvn-anno-mojo/latest/
> 
>  
> 

-- 
View this message in context: 
http://www.nabble.com/Missing%3A-org.jfrog.maven.annomojo%3Amaven-plugin-anno%3Ajar%3A1.2.4-tp19217580p19246005.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Access to remote repositories

[Yoav Landman]

Artifactory supports Nexus indexes starting with the 1.3.0 betas. If your
remote repositories do not provide an index (like the JBoss repo),
Artifactory will index the locally cached artifacts of that repository as a
fallback. Since you indicate your local JBoss cache is empty, there's
nothing to index, hence the empty results. You need to pull in some remote
artifacts form the JBoss repo first (e.g., by running mvn against a project
than needs dependencies from it), then you can expect some content in the
index.
(it's probably best to use the Artifactory users list for Artifactory
specific questions).

Yoav


buters wrote:
> 
> Thank you very much Jason,
> 
> I use m2eclipse and Artifactory, but I don't quite understand how I can
> customize that better. It works prima with local and central repositories,
> but with another as jboss one not. It seems as if Artifactory accepts
> these, but if I try to find an artifact from e.g. the jboss repository
> with eclipse "Add dependency", eclipse cannot find it if it's no copy in
> central one. Or I've not tested it often enough. Until now it runs only
> via central repository. All other repositories of Artifactory are empty.
> 
> Probably Nexus does it clever.
> Best regards, buters
> 
> 
> Jason van Zyl-2 wrote:
>> 
>> If you're talking about m2eclipse, then it's the Nexus index that you  
>> need, and you can index any Maven repository using either Nexus  
>> (nexus.sonatype.org), or just use the stand-alone indexer. m2eclipse  
>> uses the Nexus index to process your local repository. If you want  
>> JBoss artifacts to be made available ask them to index their maven  
>> repositories using Nexus.
>> 
>> On 6-Jul-08, at 12:40 PM, buters wrote:
>> 
>>>
>>> Thank you very much Tim.
>>>
>>> But it would be fine if you me explain, why am I not able to index any
>>> repository with Maven Index in eclipse besides central, local and from
>>> Artifactory. If I try Add Dependency to my project, that doesn't  
>>> exist in
>>> one of these  repositories, eclipse doesn't find this plugin, though  
>>> I've
>>> defined repository in my pom.xml. Or I must ignore eclipse errors, set
>>>  manual and try to run Maven goals?
>>>
>>> Thanks beforehand,
>>> regards, buters
>>>
>>> Tim Kettler wrote:

 buters schrieb:
> Hi,

 Hi,

> would you explain me how can I acces to e.g.
> http://repository.jboss.com/maven2/
>
> I know that I have to add this in settings.txt

 You probably mean settings.xml.

> 
>  
> artifactory
> admin
> password
>  
> 

 This is only needed if the repository is password protected. For  
 public
 repositories like central, codehaus or the jboss repository you can
 simply omit that part, just configure the repository in the  
 repositories
 section and you are done.

> It is clear in case of Artifactory which id, username and password  
> should
> be
> used.
> But which id, username and password must I use for other remote
> repositories
> (beside central)?
>
> Thanks beforehand,
> regards, buters

 -Tim

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



>>>
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/Access-to-remote-repositories-tp18300257p18303814.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> jason at sonatype dot com
>> --
>> 
>> First, the taking in of scattered particulars under one Idea,
>> so that everyone understands what is being talked about ... Second,
>> the separation of the Idea into parts, by dividing it at the joints,
>> as nature directs, not breaking any limb in half as a bad carver might.
>> 
>>-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>> 
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Access-to-remote-repositories-tp18300257p18314690.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Highly Available Archiva

[Yoav Landman]

I guess the above approach is fine if you have basic requirements from a
repository manager and are willing to go for one that:

- Treats artifacts as just files, discarding any extra metadata that cannot
be maintained using the file system, such as: who deployed an artifact, how
many times it has been downloaded, inter-artifact dependencies etc.
- Does not need security and therefore does not have to deal with storage of
ACLs.
- Does not need atomic/transactional deployments and/or concurrency controls
and willing to live with the chance of being left with half baked
deployments.

BTW, the latest Artifactory achieves HA by using *only* DB replication (not
a combination of DB and FS). HA and ACID usually go together and Artifactory
is doing it.

Yoav Landman
The Artifactory Project Lead


Jason van Zyl-2 wrote:
> 
> It's twice as hard then simply replicating a file system. Try in a  
> large organization getting DBAs and the sysadmins synced up. It's just  
> easier replicating the filesystem. Less moving parts equals better.
> 
> On 11-Apr-08, at 12:39 PM, Nick Stolwijk wrote:
>> I know Archiva is run on a JCR (JackRabbit) repository. I've setup a  
>> Jackrabbit cluster on a clustered oracle database. (So twice  
>> clustering, one for the repo, one for the db). I think it shouldn't  
>> be too hard to implement this with Archiva also.
>>
>> Hth,
>>
>> Nick S.
>>
>> Jason van Zyl wrote:
>>> Not Archiva but Nexus where the disk uses Raid 5 which is then a  
>>> network mount. The data and artifacts are shared between two  
>>> instances of Nexus and they sit behind a VIP. If the primary goes  
>>> down then the VIP flips over to the second instance that's running.  
>>> With Nexus it's simple disk replication so you could do lower tech  
>>> solutions using rsync, or not so low tech as there are tools that  
>>> do disk replication at near wire speeds. But the VIP approach has  
>>> worked for us.
>>>
>>> On 11-Apr-08, at 8:52 AM, Matthew Tordoff wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Does anyone have experience in setting up Archiva in a highly  
>>>> available manner? What is the best considered approach for doing  
>>>> this? Is it possible to replicate deployments to a server across  
>>>> all other servers in a cluster? Are there any options for  
>>>> automatic failover?
>>>>
>>>> Any advice or pointers on this would be greatly appreciated.
>>>>
>>>> Kind Regards,
>>>>
>>>> Matt T
>>>>
>>>> _
>>>> The next generation of Windows Live is here
>>>> http://www.windowslive.co.uk/get-live
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> jason at sonatype dot com
>>> --
>>>
>>> believe nothing, no matter where you read it,
>>> or who has said it,
>>> not even if i have said it,
>>> unless it agrees with your own reason
>>> and your own common sense.
>>>
>>> -- Buddha
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
> 
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
> 
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Highly-Available-Archiva-tp16635891s177p16762084.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Can I set a timeout for downloading dependency

[Yoav Landman]

If your goal is to fail the build in case of a download timeout and you wish
that timeout to be configurable, then you can use a repository manager such
as Artifactory to centrally set the desired network timeout for downloading
dependencies from a remote repository.
Your maven client will then receive the download timeout directly from
Artifactory.


youhaodeyi wrote:
> 
> ok. thanks.
> 
> Wayne Fay wrote:
>> 
>> No. Ctrl-X to cancel the build and run again with "mvn -o ..." for
>> "offline" mode.
>> 
>> Wayne
>> 
>> On 4/10/08, youhaodeyi <[EMAIL PROTECTED]> wrote:
>>>
>>> Can I set a timeout for downloading dependency jars?
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Can-I-set-a-timeout-for-downloading-dependency-tp16608218s177p16608218.html
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Can-I-set-a-timeout-for-downloading-dependency-tp16608218s177p16649676.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

RE: Nexus repository manager

[Yoav Landman]

You might also want to try out Artifactory. It has auto snapshots cleanup + a
range of other advanced features. See:
http://www.jfrog.org/confluence/display/RTF/Welcome+to+Artifactory%21

(as the project lead I am of course biased ;)


Hayes, Peter wrote:
> 
> I did not know Nexus was going to be commercial.  Thanks for the info.
> 
> Pete 
> 
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 12, 2008 5:30 PM
> To: Maven Users List
> Subject: Re: Nexus repository manager
> 
> Nexus is a commercial product from Sonatype, so you should probably
> contact them via their website for more information.
> 
> If you are interested in snapshot cleanup that works today, you might
> try Archiva: http://maven.apache.org/archiva/ :)
> 
> Cheers,
> Brett
> 
> On 13/02/2008, Hayes, Peter <[EMAIL PROTECTED]> wrote:
>> Is there any update on the Nexus repository manager?  I am interested
> in
>> snapshot cleanup.
>>
>> Thanks,
>>
>> Peter Hayes
>> Architecture & Shared Technology Services | Fidelity Investments
>> Management Technology
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> -- 
> Brett Porter
> Blog: http://blogs.exist.com/bporter/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Nexus-repository-manager-tp15442472s177p15467151.html
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Trying to setup a Maven Shared Repository

[Yoav Landman]

The URL that should be browsable from the UI with the out-of-the-box
installation is: http://:8081/artifactory
I'd also suggest you use 1.2.5-rc1, instead of rc-0.
You might want to take this to the artifactory-users list...


charliec wrote:
> 
> Hello, 
> I downloaded artifactory and executed the batch script artifactory.bat to
> start it.  I added the following to the settings.xml file:
>
>   artifactory
>   *
>   http://:8081/artifactory/repo
>   Artifactory
>
> However, when I execute Maven, I still receive the following error:
> Caused by: java.io.IOException: Server returned HTTP response code: 503
> for URL:
> 
> http://:8081/artifactory/repo/org/apache/maven/plugins/maven-resource
> s-plugin/maven-metadata.xml
> 
> I noticed the machine that when I try to bring up
> http://:8081 on the machine that has artifactory installed,
> I receive the following message:
> 
> No context on this server matched or handled this request.
> Contexts known to this server are: 
> /artifactory --->
> [EMAIL 
> PROTECTED]/artifactory,jar:file:/D:/artifactory-1.2.5-rc0/webapps/artifactory.war!/}
>  
> 
> The documentation for artifactory says to set up maven to use artifactory
> proxy, just configure a maven repository with the following URL: 
> http://[your server name]:[port]/artifactory/repo 
> 
> What do I need to accomplish this?  Thanks.
> 
> 
> 
> mmistroni wrote:
>> 
>> Hello,
>>  i m trying to do same with artifactory.. worked fine so far.. i
>> recommend u
>> have  a look at that
>> 
>> regards
>>  marco
>> 
>> On 10/23/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
>>>
>>> Simply putting an HTTP server on top of your personal .m2 directory
>>> (local repo cache) is not sufficient. The metadata in a real Maven
>>> repo is different than what is in your private local repo cache.
>>>
>>> Please look at Archiva, Proximity, Artifactory, etc for a "real" Maven
>>> repo solution.
>>>
>>> Wayne
>>>
>>> On 10/23/07, charliec <[EMAIL PROTECTED]> wrote:
>>> >
>>> > Hello,
>>> > I'm trying to setup a shared repository that mirrors the central
>>> repository
>>> > so other team members can download from this repository instead of
>>> accessing
>>> > the central.  I've created a Virtaul Directory in IIS that points to
>>> my
>>> .m2
>>> > repository.  I can access this repostory on another machine via the
>>> browser
>>> > using url such as the following:  http:///repository. 
>>> On
>>> the
>>> > other machine, I added the following to my pom.xml file:
>>> > 
>>> > 
>>> > central
>>> > http:///repository
>>> > name>Maven Repository Manager running on repo.company.com
>>> 
>>> > 
>>> >  
>>> > 
>>> >   
>>> >central
>>> >IMaven Repository Manager running on repo.company.com
>>> >http:///repository
>>> >
>>> > 
>>> >
>>> > When I run mvn install, I receive the error below.   It doesn't even
>>> try
>>> to
>>> > access the shared repository.  Please help.  Any assistance would be
>>> greatly
>>> > appreciated.  Thanks.
>>> >
>>> >
>>> > + Error stacktraces are turned on.
>>> > Maven version: 2.0.7
>>> > Java version: 1.5.0_12
>>> > OS name: "windows xp" version: "5.1" arch: "x86"
>>> > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents
>>> and
>>> > Settin
>>> > gs\COSS\.m2\plugin-registry.xml'
>>> > [DEBUG] Building Maven global-level plugin registry from:
>>> > 'C:\maven-2.0.7\conf\p
>>> > lugin-registry.xml'
>>> > [INFO] Scanning for projects...
>>> > [INFO]
>>> >
>>> -
>>> > ---
>>> > [INFO] Building my-app
>>> > [INFO]task-segment: [install]
>>> > [INFO]
>>> >
>>> -
>>> > ---
>>> > [INFO] artifact
>>> org.apache.maven.plugins:maven-resources-plugin:checking
>>> > for up
>>> > dates from central
>>> > [WARNING] repository metadata for: 'artifact
>>> > org.apache.maven.plugins:maven-reso
>>> > urces-plugin' could not be retrieved from repository: central due to
>>> an
>>> > error: E
>>> > rror transferring file
>>> > [INFO] Repository 'central' will be blacklisted
>>> > [DEBUG] Exception
>>> > org.apache.maven.wagon.TransferFailedException: Error transferring
>>> file
>>> > at
>>> > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputD
>>> > ata(LightweightHttpWagon.java:104)
>>> > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
>>> > at
>>> > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(D
>>> > efaultWagonManager.java:462)
>>> > at
>>> > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMeta
>>> > data(DefaultWagonManager.java:363)
>>> > at
>>> > org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada
>>> > taManager.resolveAlways(DefaultRepositoryMetadataManager.java:364)
>>> > at
>>> > org.apache.maven.artifact.repository.me

RE: Maven Proxy

[Yoav Landman]

Just a note about the Artifactory UI - Artifactory 1.2.5 offers additional
lightweight directory-style repository browsing with bookmarkable artifact
URLs. We also improved the ajax tree browsing experience, so you're welcome
to give this version a test drive (see:
http://www.nabble.com/-ANN--Artifactory-1.2.5-rc1-t4612108.html)


dhoffer wrote:
> 
> We used to use Proximity and now use Artifactory 1.2.1.  There are
> pros/cons of each.
> 
> We switched from Proximity because it did not support artifact upload,
> this may have changed since then.  Artifactory has good download/upload
> HTTP support.  
> 
> We added service running to Artifactory which makes it run real nice.
> The biggest downside to it is the SLOW...SLOW speed of the UI browser
> and lack of URL to artifacts (stored internally in derby).
> 
> 
> 
> -Original Message-
> From: Denis Bessmertniy
> [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 12, 2007 5:04 AM
> To: 'Maven Users List'
> Subject: Maven Proxy
> 
> Hi, May you advise to me a good maven proxy?
> I know only http://proximity.abstracthorizon.org. Is it good?
> 
> Maybe you know something better?
> -
> Denis
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Maven-Proxy-tf4612261s177.html#a13269954
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: Is there any way to tell who deployed into the repository?

[Yoav Landman]

Artifactory supports this. Each artifact's metadata includes, among other
things, the original deployer identity.


Baz-6 wrote:
> 
> All,
> 
> Is there any way to tell who deployed files into the repository?
> 
> Thanks.
> 
> A.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Is-there-any-way-to-tell-who-deployed-into-the-repository--tf4588701s177.html#a13099282
Sent from the Maven - Users mailing list archive at Nabble.com.


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

RE: Repos Managers : Archiva, artifactory, proximity, file://

[Yoav Landman]

FYI,

The upcoming release of Artifactory (available in RC now) comes with a light
directory-style repository browsing mode and also has an improved ajax tree
browsing by automatically compacting empty folders and using more relaxed
node auto-expand behavior.
Artifactory now also offers automatic unique snapshots removal (mentioned
before), as well as improved backup features and full system state import
export from/to a distributable zip format for easier future upgrades (ala
JIRA/Confleuence).

More details are available here:
http://www.nabble.com/-ANN--Artifactory-1.2.5-rc0-t4506282.html

-Yoav
The Artifactory Team


dhoffer wrote:
> 
> We use Artifactory proxy one for snapshots and one for releases (this
> was due to an early bug where it did not handle the differences
> correctly-this is reported to be fixed).
> 
> We used to use Proximity...had to switch because it did not support
> deployment (no web upload).
> 
> Thoughts, if Proximity had good upload we likely would not have
> switched...but they didn't.
> 
> Artifactory seems a little better overall but the web UI is SLOW.
> Thankfully we don't need UI access to the artifacts all that often...if
> we did it wouldn't be tolerable.  The speed as a proxy is fine which is
> what matters the most to us.
> 
> I too am not crazy about Artifactory's db storage but since they have
> import/export its okay.
> 
> -Dave
> 
> -Original Message-
> From: Bernd Stolle [mailto:[EMAIL PROTECTED] 
> Sent: Monday, September 24, 2007 3:53 PM
> To: Maven Users List
> Subject: Re: Repos Managers : Archiva, artifactory, proximity, file://
> 
> Julien Graglia wrote:
>> I also have heard about proximity, but the live demo  is down since ..
>> pfui... 2 months... not sure I want to use that..
> 
> Apparently they are restructuring the site. You can get an (older) SVN
> snapshot
> here: http://proximity.abstracthorizon.org/deploy/nightly/
> 
> SVN shows recent activity:
> http://trac.abstracthorizon.org/proximity/browser
> 
>> So here is my question : what do you use? any of those 4 "repos
>> manager", another?
>> 
>> Here is my needs :
>> use it as a maven repository
>> deploy artifacts (file or dav...) : snapshots and releases
>> clean olds snapshots
> 
> I used Artifactory for a while and was not happy with the database
> storage and
> the configuration, so i decided to try Proximity instead:
> 
> pro:
> quicker than Artifactory
> stores artifacts in the filesystem
> supports multiple repositories with multiple sources
> supposedly supports WebDAV (untested)
> nightly snapshot remover job
> cons:
> configuration is "experts only", you manually have to modify the
> spring
> configuration to add/remove repositories
> cached artifacts don't get indexed automatically for the search
> site, so
> you manually have to wait for the reindex job, or trigger it manually
> 
> MfG,
> 
> Bernd
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Repos-Managers-%3A-Archiva%2C-artifactory%2C-proximity%2C-file%3A---tf4509991s177.html#a12870062
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: artifactory - maintaining a public-repo cache

[Yoav Landman]

> 1) So if the ids is just the logical name inside maven , what
> difference does it make if i name the Id as "central" or "snapshot" as
> you suggested earlier, and i assume thats the only change you are
> suggesting to my earlier configuration in the pom.
> 

It matters to Maven if you wish to override Maven's built-in "central" and
"snapshots" repositories (instead of using mirroring).

> 2) Isn't that how it should be, given that if the artifact isn't found
> in the local cache (which means that it wasnt refered/cached earlier
> and hence the public repo should be looked up)

It is how it should be and how it is inside Artifactory. What I was
referring to is directly from your Maven client, which is normally not
desired when having a corporate repository facade.

> 
> On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
> >
> > 1) No. The id is just a logical name inside Maven. It is the URL that
> > matters. If you use the http://localhost:8080/artifactory/repo you point
> at
> > Artifactory's global virtual repository and an ordered search is
> conducted
> > on configured repositories, including caches, according to the policies
> set
> > on each repository
> > (http://www.jfrog.org/sites/artifactory/latest/faqs.html#repositories).
> >
> > 2) Yes, it does work, but repo1 will still be consulted right after
> > Artifactory (in case an artifact could not be resolved with the current
> > Artifactory configuration), which is normally not what you want.
> >
> > mfs wrote:
> > >
> > > Hi Yoav,
> > >
> > > It seems to be working now...Well actually the artifacts i was
> > > refering to were actually the plugins (which were always being
> > > downloaded from the maven public repo i.e. repo1), and after adding
> > > the pluginrepositories section (as below) in pom those are now being
> > > cached/downloaded from the locally configured repository...now your
> > > last reply has got me a bit confused, 1) arent the ids suppose to be
> > > whatever you have named them (in the key tag) in
> > > artifactory.config.xml because thats from where you want to download
> > > your artifact/plugin 2) why is it working like this..
> > >
> > > 
> > >   
> > >   maven-public-repo-cache
> > >   http://localhost:8080/artifactory/repo
> > >   
> > >   false
> > >   
> > >   
> > > 
> > >
> > >
> > >
> > > On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
> > >>
> > >> The repository id must be "central" to override repo1 (for releases,
> or
> > >> "snapshots" to override it for snapshots).
> > >> If you wish to use a different id, then you have to use mirroring in
> > >> settings.xml.
> > >>
> > >> HTH
> > >>
> > >>
> > >> mfs wrote:
> > >> >
> > >> > Hi Yoav,
> > >> >
> > >> > Thanks for the quick follow..so basically among the two approaches
> > >> > suggested, the first is the one i have opted, and have defined the
> > >> > maven-public-repository-cache in the parent pom as it states
> (instead
> > >> > of settings.xml)..or am i still missing something..
> > >> >
> > >> > Farhan.
> > >> >
> > >> > On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
> > >> >>
> > >> >> You need to make Artifactory either a mirror or a replacement for
> the
> > >> >> "repo1"
> > >> >> central repository by following a simple Maven configuration. See:
> > >> >> http://www.jfrog.org/sites/artifactory/latest/maven.html
> > >> >>
> > >> >>
> > >> >> mfs wrote:
> > >> >> >
> > >> >> > Dear All,
> > >> >> >
> > >> >> > I have setup a maven public repository cache so as to maintain
> the
> > >> >> > artifacts used commonly (within the organization) and hence not
> > >> >> > require a download everytime from a maven public repository and
> btw
> > >> i
> > >> >> > am using Artifactory as the Repository Manager.
> > >> >> >
> > >> >> > So in order to achieve the above i have defined the foll

Re: artifactory - maintaining a public-repo cache

[Yoav Landman]

1) No. The id is just a logical name inside Maven. It is the URL that
matters. If you use the http://localhost:8080/artifactory/repo you point at
Artifactory's global virtual repository and an ordered search is conducted
on configured repositories, including caches, according to the policies set
on each repository
(http://www.jfrog.org/sites/artifactory/latest/faqs.html#repositories).

2) Yes, it does work, but repo1 will still be consulted right after
Artifactory (in case an artifact could not be resolved with the current
Artifactory configuration), which is normally not what you want.

mfs wrote:
> 
> Hi Yoav,
> 
> It seems to be working now...Well actually the artifacts i was
> refering to were actually the plugins (which were always being
> downloaded from the maven public repo i.e. repo1), and after adding
> the pluginrepositories section (as below) in pom those are now being
> cached/downloaded from the locally configured repository...now your
> last reply has got me a bit confused, 1) arent the ids suppose to be
> whatever you have named them (in the key tag) in
> artifactory.config.xml because thats from where you want to download
> your artifact/plugin 2) why is it working like this..
> 
> 
>   
>   maven-public-repo-cache
>   http://localhost:8080/artifactory/repo
>   
>   false
>   
>   
> 
> 
> 
> 
> On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
>>
>> The repository id must be "central" to override repo1 (for releases, or
>> "snapshots" to override it for snapshots).
>> If you wish to use a different id, then you have to use mirroring in
>> settings.xml.
>>
>> HTH
>>
>>
>> mfs wrote:
>> >
>> > Hi Yoav,
>> >
>> > Thanks for the quick follow..so basically among the two approaches
>> > suggested, the first is the one i have opted, and have defined the
>> > maven-public-repository-cache in the parent pom as it states (instead
>> > of settings.xml)..or am i still missing something..
>> >
>> > Farhan.
>> >
>> > On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
>> >>
>> >> You need to make Artifactory either a mirror or a replacement for the
>> >> "repo1"
>> >> central repository by following a simple Maven configuration. See:
>> >> http://www.jfrog.org/sites/artifactory/latest/maven.html
>> >>
>> >>
>> >> mfs wrote:
>> >> >
>> >> > Dear All,
>> >> >
>> >> > I have setup a maven public repository cache so as to maintain the
>> >> > artifacts used commonly (within the organization) and hence not
>> >> > require a download everytime from a maven public repository and btw
>> i
>> >> > am using Artifactory as the Repository Manager.
>> >> >
>> >> > So in order to achieve the above i have defined the following in the
>> >> > artifactory-config.xml
>> >> >
>> >> > 
>> >> > maven-public-repo
>> >> > true
>> >> > false
>> >> >
>> org/artifactory/**,org/jfrog/**
>> >> > http://repo1.maven.org/maven2
>> >> >  
>> >> >
>> >> > and similarly in the pom.xml i have defined the following entry so
>> as
>> >> > to refer to it..
>> >> >
>> >> >  
>> >> >   maven-public-repo-cache
>> >> >   xyz Repository
>> >> >   http://localhost:8080/artifactory/repo
>> >> >   default
>> >> >   
>> >> > true
>> >> >   
>> >> >   
>> >> >false
>> >> >   
>> >> >  
>> >> >
>> >> > Now the problem is that the repository DOES cache artifacts but NOT
>> >> > all of the artifacts that are downloaded (from the public repo) and
>> >> > hence for them it still refers to the repo1.maven.org, now i am not
>> >> > sure why is that the case..why is it not caching everything ?
>> >> >
>> >> > Thanks in advance and Regards,
>> >> >
>> >> > Farhan.
>> >> >
>> >> >
>> -
>> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>

Re: artifactory - maintaining a public-repo cache

[Yoav Landman]

The repository id must be "central" to override repo1 (for releases, or
"snapshots" to override it for snapshots).
If you wish to use a different id, then you have to use mirroring in
settings.xml.

HTH


mfs wrote:
> 
> Hi Yoav,
> 
> Thanks for the quick follow..so basically among the two approaches
> suggested, the first is the one i have opted, and have defined the
> maven-public-repository-cache in the parent pom as it states (instead
> of settings.xml)..or am i still missing something..
> 
> Farhan.
> 
> On 8/20/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
>>
>> You need to make Artifactory either a mirror or a replacement for the
>> "repo1"
>> central repository by following a simple Maven configuration. See:
>> http://www.jfrog.org/sites/artifactory/latest/maven.html
>>
>>
>> mfs wrote:
>> >
>> > Dear All,
>> >
>> > I have setup a maven public repository cache so as to maintain the
>> > artifacts used commonly (within the organization) and hence not
>> > require a download everytime from a maven public repository and btw i
>> > am using Artifactory as the Repository Manager.
>> >
>> > So in order to achieve the above i have defined the following in the
>> > artifactory-config.xml
>> >
>> > 
>> > maven-public-repo
>> > true
>> > false
>> > org/artifactory/**,org/jfrog/**
>> > http://repo1.maven.org/maven2
>> >  
>> >
>> > and similarly in the pom.xml i have defined the following entry so as
>> > to refer to it..
>> >
>> >  
>> >   maven-public-repo-cache
>> >   xyz Repository
>> >   http://localhost:8080/artifactory/repo
>> >   default
>> >   
>> > true
>> >   
>> >   
>> >false
>> >   
>> >  
>> >
>> > Now the problem is that the repository DOES cache artifacts but NOT
>> > all of the artifacts that are downloaded (from the public repo) and
>> > hence for them it still refers to the repo1.maven.org, now i am not
>> > sure why is that the case..why is it not caching everything ?
>> >
>> > Thanks in advance and Regards,
>> >
>> > Farhan.
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/artifactory---maintaining-a-public-repo-cache-tf4301698s177.html#a12245037
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/artifactory---maintaining-a-public-repo-cache-tf4301698s177.html#a12245254
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: artifactory - maintaining a public-repo cache

[Yoav Landman]

You need to make Artifactory either a mirror or a replacement for the "repo1"
central repository by following a simple Maven configuration. See:
http://www.jfrog.org/sites/artifactory/latest/maven.html


mfs wrote:
> 
> Dear All,
> 
> I have setup a maven public repository cache so as to maintain the
> artifacts used commonly (within the organization) and hence not
> require a download everytime from a maven public repository and btw i
> am using Artifactory as the Repository Manager.
> 
> So in order to achieve the above i have defined the following in the
> artifactory-config.xml
> 
> 
> maven-public-repo
> true
> false
> org/artifactory/**,org/jfrog/**
> http://repo1.maven.org/maven2
>  
> 
> and similarly in the pom.xml i have defined the following entry so as
> to refer to it..
> 
>  
>   maven-public-repo-cache
>   vAudit Repository
>   http://localhost:8080/artifactory/repo
>   default
>   
> true
>   
>   
>false
>   
>  
> 
> Now the problem is that the repository DOES cache artifacts but NOT
> all of the artifacts that are downloaded (from the public repo) and
> hence for them it still refers to the repo1.maven.org, now i am not
> sure why is that the case..why is it not caching everything ?
> 
> Thanks in advance and Regards,
> 
> Farhan.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/artifactory---maintaining-a-public-repo-cache-tf4301698s177.html#a12245037
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: maven proxies

[Yoav Landman]

Just to complete/correct the picture:
Artifactory HAS the kind of security you describe, in fact it might be even
a bit more powerful than that - see:
http://www.jfrog.org/sites/artifactory/latest/security.html
It also supports blacking out repositories and include/exclude artifact
patterns (in case you don't want to share with the rest of the world on the
way to repo1 the fact that your company is working on a new version of
product X).
You may find the following TSS article which includes a comparative report
useful:
http://www.theserverside.com/tt/articles/article.tss?l=SettingUpMavenRepository

I am of course very Artifactory oriented ;) (The TSS article is an
independent one, however).

HTH,

-Yoav


Brett Porter wrote:
> 
> Hi Maarten,
> 
> I'd encourage you to take a look at all 3 as each has some of the
> features and it depends on the balance you give each. For your
> options, you'd probably be looking at Proximity or Archiva (bear in
> mind that Archiva is only available as an alpha, and that I am biased
> towards it :).
> 
> All can cope with multiple repositories. Proximity has the most
> configurable proxying, and Artifactory probably had the smoothest set
> up (though I think Archiva is pretty close there).
> 
> Artifactory is the only one with built in backup (it stores all
> artifacts in a content repository and metadata in a database). Archiva
> and Proximity both store solely on the filesystem (Archiva uses a
> database too, but it can be safely rebuilt if lost), so are
> straightforward to back up (eg with rsync).
> 
> I believe Proximity would do best at blacklisting though there is
> support in Archiva too. You could back any repository with DSMP as
> well to provide that feature if needed.
> 
> I didn't dig into detail on the security features of each, but I don't
> think Artifactory has what you want. I believe proximity could be
> extended/configured to do that, and Archiva has it up front.
> 
> Hope that covers it!
> 
> Cheers,
> Brett
> 
> On 30/06/07, maarten roosendaal <[EMAIL PROTECTED]> wrote:
>> Brett,
>>
>> We are in the progress of moving to Maven 2 and at the moment we just use
>> a local drive (c:) or a shared drive as a repository.
>>
>> We are trying to come up with a standard for the whole organisation and
>> for all projects executed internally. So what we need is 1 central
>> company wide repository, 2 repositories (1 SNAPSHOT and one for
>> deliveries) for each project. What we need is a proxy which is easily
>> manageble, has flexible security (per project, per user), backup options,
>> policies regarding blacklisted dependencies.
>>
>> What would you recommond?
>>
>> Thanks,
>> Maarten
>>
>> - Original Message 
>> From: Brett Porter <[EMAIL PROTECTED]>
>> To: Maven Users List 
>> Sent: Saturday, June 30, 2007 7:32:08 AM
>> Subject: Re: maven proxies
>>
>> I've done a little review of those that are publicly available that
>> I'll post soon, but if you have any specific questions I'd be happy to
>> answer them from my evaluation.
>>
>> Cheers,
>> Brett
>>
>> On 30/06/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
>> > Archiva
>> > Artifactory
>> > Gatekeeper
>> > Proximity
>> > and I'm sure there are others.
>> >
>> > I'm not sure which is "best" as I haven't really used them all, and
>> > don't have the level of expertise with each product to really say
>> > "this one for this reason".
>> >
>> > Wayne
>> >
>> > On 6/29/07, Brad O'Hearne <[EMAIL PROTECTED]> wrote:
>> > > I am currently running maven-proxy-webapp (a build from a long time
>> ago)
>> > > and wanted to ask what other maven proxy apps were out there. What
>> other
>> > > ones are there, and is there any one better than the others?
>> > >
>> > > Thanks,
>> > >
>> > > Brad
>> > >
>> > > -
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>>
>>
>> 
>> Food fight? Enjoy some healthy debate
>> in the Yahoo! Answers Food & Drink Q&A.
>> http://answers.yahoo.com/dir/?link=list&sid=396545367
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/maven-pro

Re: Maven with NTLM

[Yoav Landman]

You could also install Artifactory and use it as an organizational
maven-proxy to external repositories that communicates through your NTLM
proxy. We have this set up in a number of places and it works seamlessly.
http://www.jfrog.org/sites/artifactory/latest/configuration.html (look for
"Using a NTLM or Simple Proxy" at the bottom).


Sammpathkumar, C wrote:
> 
> Hi All,
> 
> I am struggling with Maven to make I work with NTLM authentication in
> our office network.
> 
> I tried customizing settings.xml and giving the environment properties
> in commandline with details of the proxy. But I always get the below
> error:
> Caused by: java.net.ProtocolException: Server redirected too many  times
> (20)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnec
> tion.java:1160)
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData
> (LightweightHttpWagon.java:83)
> ... 23 more
> 
> In settings.xml, I have the below:
> 
>   true
>   http
>   132.186.65.234
>   8080
>   in002/sc001179
>   XX
> 
>   
>  <> 
> Also tried with the below command:
> 
> mvn archetype:create -X -e
> -DarchetypeGroupId=org.apache.maven.archetypes
> -DgroupId=com.mycompany.app -DartifactId=my-app
> Dmaven.proxy.ntlm.host=132.186.67.239 -Dmaven.proxy.host=localhost
> -Dmaven.proxy.ntlm.domain=IN002 -Dmaven.proxy.port=9100
> -Dmaven.proxy.username=sc001179 -Dmaven.proxy.password=XXX
> 
> Please help me to get out of this problem.
> 
> Thanks in advance,
> 
> Regards,
> Sammpath
> 
> 
> 
> Disclaimer:
> This e-mail may contain trade secrets or privileged, undisclosed or
> otherwise confidential information. If you have received this e-mail in
> error, you are hereby notified that any review, copying or distribution of
> it is strictly prohibited. Please inform us immediately and destroy the
> original transmittal. Thank you for your cooperation.
> 
> D:\ProgramFiles\maven-2.0.6\test>mvn archetype:create -X -e
> -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.mycompany.app
> -DartifactId=my-app >out.txt
> + Error stacktraces are turned on.
> Maven version: 2.0.6
> [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and
> Settings\ccb2501\.m2\plugin-registry.xml'
> [DEBUG] Building Maven global-level plugin registry from:
> 'D:\ProgramFiles\maven-2.0.6\bin\..\conf\plugin-registry.xml'
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO] org.codehaus.mojo: checking for updates from central
> [WARNING] repository metadata for: 'org.codehaus.mojo' could not be
> retrieved from repository: central due to an error: Error transferring
> file
> [INFO] Repository 'central' will be blacklisted
> [DEBUG] Exception
> org.apache.maven.wagon.TransferFailedException: Error transferring file
>   at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104)
>   at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
>   at
> org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:462)
>   at
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:363)
>   at
> org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:364)
>   at
> org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:97)
>   at
> org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:101)
>   at
> org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:85)
>   at
> org.apache.maven.plugin.DefaultPluginMappingManager.getByPrefix(DefaultPluginMappingManager.java:59)
>   at
> org.apache.maven.plugin.DefaultPluginManager.getPluginDefinitionForPrefix(DefaultPluginManager.java:149)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1451)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:386)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at org.codehaus.classworl

Re: Re : Re : Re : Re : Re : Re : Re : Help setup local proxy for Maven2 (Please)

[Yoav Landman]

Not anymore. Starting with 1.2.1rc0 the codebase is compiled against 1.5 and
the war can be deployed inside any java5 servlet container.
(see: https://www.jfrog.org/jira/browse/RTFACT-75)


Kathryn Huxtable wrote:
> 
> The *only* problem with Artifactory is that it seems to require Java6 and
> we're not yet running that on anything.
> 
> -K
> 
> 
> On 4/24/07 3:28 PM, "Wayne Fay" <[EMAIL PROTECTED]> wrote:
> 
>> The general concept behind all of these Maven Proxy tools is the same.
>> If one works for you and others do not, then I would just use that
>> one.
>> 
>> Wayne
>> 
>> On 4/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> is there an additionnal configuration that I missed, one to make Tomcat
>>> access the internet for central mirroring ?
>>> 
>>> because
>>> when I installed Artifactory (and reinstalled maven 2.0.6 right now !)
>>> everything is looking fine (Artifactory looking up external
>>> repositories from the first hit !)
>>> 
>>> this is the first log :
>>> (sorry for the first mail )
>>> 
>>> (miko$oft bad commad prompt truncated my log ! grrr !)
>>> 
>>> 164K downloaded
>>> Downloading: 
>>> http://localhost:8081/artifactory/repo/commons-httpclient/commons-h
>>> ttpclient/2.0.2/commons-httpclient-2.0.2.jar
>>> 220K downloaded
>>> WAGON_VERSION: 1.0-beta-2
>>> [INFO] 
>>> -
>>> ---
>>> [INFO] Building Unnamed - com:TutelecOJV-v1.3:jar:1.3
>>> [INFO]task-segment: [compile]
>>> [INFO] 
>>> -
>>> ---
>>> [INFO] artifact org.apache.maven.plugins:maven-resources-plugin:
>>> checking for
>>> up
>>> dates from central
>>> Downloading: 
>>> http://localhost:8081/artifactory/repo/org/apache/maven/plugins/mav
>>> en-resources-plugin/2.2/maven-resources-plugin-2.2.pom
>>> 1K downloaded
>>> Downloading: 
>>> http://localhost:8081/artifactory/repo/org/apache/maven/plugins/mav
>>> en-plugins/1/maven-plugins-1.pom
>>> 3K downloaded
>>> Downloading: 
>>> http://localhost:8081/artifactory/repo/org/apache/maven/maven-paren
>>> t/1/maven-parent-1.pom
>>> 6K downloaded
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Re-%3A-Re-%3A-Re-%3A-Re-%3A-Re-%3A-Re-%3A-Re-%3A-Help-setup-local-proxy-for-Maven2-%28Please%29-tf3641041s177.html#a10175631
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: How to set up internal repository.

[Yoav Landman]

Did you try using Artifactory or a similar solution -

http://www.jfrog.org/sites/artifactory/latest/introduction.html


Srinivasulu G-TLS,Chennai wrote:
> 
> 
> Hi,
> 
>  
> 
>  How to do this:   "setting our own internal repository and
> make it accessible to all the developers in the team without downloading
> from the maven2 default central repository".
> 
>  
> 
> Could anyone please help regarding this.
> 
>  
> 
> What changes we have to make for pom.xml and settings.xml?
> 
>  
> 
> Because I am not able to find the solution for this.
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Regards
> Srinivas G
> 
>  
> 
>  
> 
> 
> 
> DISCLAIMER:
> ---
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in 
> this email are solely those of the author and may not necessarily reflect
> the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of 
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have 
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and 
> attachments please check them for viruses and defect.
> 
> ---
> 

-- 
View this message in context: 
http://www.nabble.com/How-to-set-up-internal-repository.-tf3466862s177.html#a9674084
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: [m2] [ANN] Artifactory - new Maven 2 proxy repository

[Yoav Landman]

We have just released a minor version update for Artifactory (1.2.0.1) which
fixes a couple of known reported issues, so you are welcome to use it.
Release notes are here:
http://sourceforge.net/project/shownotes.php?release_id=491127&group_id=175347


Yoav  Landman wrote:
> 
> Hi all,
> 
> We would like to announce the immediate availability of Artifactory, a
> Maven 2 enterprise proxy.
> 
> Artifactory offers advanced proxying, caching and security facilities to
> answer the needs of a robust, reproducible and independent build
> environment using Maven 2.
> It uses a JSR-170 Java Content Repository (JCR) for storage, which makes
> it extremely easy to manage searchable metadata, and provide extended
> features such as security, transacted operations, auditing, locking, etc.
> 
> Artifactory is distributed under APLv2 at
> http://artifactory.sourceforge.net.
> It is currently available as a downloadable archive, that can be run out
> of the box (with default settings). An install script to run it as a Linux
> service is also provided.
> A (limited) guest live demo is available at
> http://www.jfrog.org/artifactory/
> 
> You are welcome to give it a go!
> 
> Cheers,
> 
> Yoav Landman,
> The Artifactory Team
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--Artifactory---new-Maven-2-proxy-repository-tf3344299s177.html#a9372267
Sent from the Maven - Users mailing list archive at Nabble.com.


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

Re: [m2] [ANN] Artifactory - new Maven 2 proxy repository

[Yoav Landman]

 aye
>> > 1.0-SNAPSHOT
>> > jar
>> >
>> > 
>> > 
>> > artifactory-server
>> > dav:http://localhost:8080/artifactory/[EMAIL PROTECTED]
>> > 
>> > 
>> > 
>> >
>> > 
>> > 
>> > 
>> > org.apache.maven.wagon
>> > wagon-webdav
>> > 1.0-beta-2
>> > 
>> > 
>> > 
>> > 
>> >
>> > and from where this pom sits you can run:
>> > mvn deploy:deploy-file -DrepositoryId=artifactoryServer
>> > -Durl=dav:http://...
>> > -Dfile=.. -DgroupId=... -DartifactId=... -Dversion=... -Dtype=...
>> > -Dclassifier=...
>> >
>> > Hope it helps.
>> >
>> > On 3/6/07, Reinhard Nägele < [EMAIL PROTECTED]> wrote:
>> > >
>> > >
>> > > This looks quite interesting, and I started to play around with it.
>> > > The biggest problem is the poor documentation. With Jetty, you can
>> > > quickly start it out of the box. Accessing the Web interface, you are
>> > > then stuck with the login screen because the default credentials are
>> > > not documented anywhere. I had to connect to the embedded Derby
>> database
>> > to find them out.
>> > >
>> > > I then moved on and tried to set it up on Tomcat. After fiddling yet
>> > > for another while, I discovered it needs a system property to be
>> > > present. I don't like that. Anyways, it seems to be running fine now.
>> > >
>> > > The next step where I need help is in deploying to a local
>> repository.
>> > > I tried both HTTP and DAV without success. Using HTTP, the artifact
>> > > was uploaded and then yielded an HTTP 500 error, DAV didn't work
>> > > because the wagon was not found, even though I installed it and
>> > > followed all the tips I found for using WebDAV with Maven.
>> > >
>> > > I am stuck now and would appreciate further help. I'd like to repeat
>> > > that the product does look promising. Chances are good that we may
>> > > replace Maven Proxy with it once we get these problems sorted. And
>> > > please enhance the docs!
>> > >
>> > > Thanks,
>> > > Reinhard
>> > >
>> > >
>> > > -Original Message-
>> > > From: Yoav Landman [mailto:[EMAIL PROTECTED]
>> > > Sent: Montag, 5. März 2007 07:14
>> > > To: users@maven.apache.org
>> > > Subject: Re: [m2] [ANN] Artifactory - new Maven 2 proxy repository
>> > >
>> > >
>> > > Well, Artifactory actually started out as a series as patches on
>> > > m2proxy and ended in a complete rewrite of it. The extras that we did
>> > > came from real world requirements.
>> > > The old m2proxy might still answer your every need in your
>> development
>> > > environment, and that's fine. Artifactory is used today by a couple
>> of
>> > > very large distributed development environments and that's where it
>> > > really makes a difference. It offers everything that m2proxy used to
>> > > offer + enterprise features such as:
>> > > - Ability to deploy a mesh of proxies, each site proxying another.
>> > > - Enhanced security for controlling who can deploy/undeploy to where.
>> > > - Multiple local repositories support with control on what can be
>> > > deployed to each repo, either by include/exclude patterns or by
>> > snapshot/releases.
>> > > - Optional authenticated download of artifacts from local
>> repositories
>> > > - Web based deployment, including extraction a pom embedded in a
>> > > deployed jar for a single transaction deployment of both jar and its
>> > pom.
>> > > - HTTP(s) or WebDav deployment
>> > > - Advanced indexing
>> > > - Much improved web UI
>> > > There's a more detailed feature description at:
>> > > http://www.jfrog.org/sites/artifactory/latest/introduction.html
>> > >
>> > > Yoav
>> > >
>> > >
>> > > Kalle Korhonen-2 wrote:
>> > > >
>> > > > Interesting. To this date, there's at least maven-proxy (
>> > > > http://maven-proxy.codehaus.org/ ), Proximity (
>> >

Re: [m2] [ANN] Artifactory - new Maven 2 proxy repository

[Yoav Landman]

Well, Artifactory actually started out as a series as patches on m2proxy and
ended in a complete rewrite of it. The extras that we did came from real
world requirements.
The old m2proxy might still answer your every need in your development
environment, and that's fine. Artifactory is used today by a couple of very
large distributed development environments and that's where it really makes
a difference. It offers everything that m2proxy used to offer + enterprise
features such as:
- Ability to deploy a mesh of proxies, each site proxying another.
- Enhanced security for controlling who can deploy/undeploy to where.
- Multiple local repositories support with control on what can be deployed
to each repo, either by include/exclude patterns or by snapshot/releases.
- Optional authenticated download of artifacts from local repositories
- Web based deployment, including extraction a pom embedded in a deployed
jar for a single transaction deployment of both jar and its pom.
- HTTP(s) or WebDav deployment
- Advanced indexing
- Much improved web UI
There's a more detailed feature description at:
http://www.jfrog.org/sites/artifactory/latest/introduction.html

Yoav


Kalle Korhonen-2 wrote:
> 
> Interesting. To this date, there's at least maven-proxy (
> http://maven-proxy.codehaus.org/), Proximity (
> http://proximity.abstracthorizon.org/), Archiva (
> http://maven.apache.org/archiva/) and now, Artifactory, for more of less
> the
> same purpose. They are all Apache2 type licensed. We still use
> maven-proxy,
> and while it's only at version 0.2 and its development has stopped, we
> haven't seen any issues with it. Are any of these based on other's
> codebase
> or separate efforts and does anybody have any idea what the practical
> differences between all these are to the end user?
> 
> Kalle
> 
> On 3/4/07, Yoav Landman <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hi all,
>>
>> We would like to announce the immediate availability of Artifactory, a
>> Maven
>> 2 enterprise proxy.
>>
>> Artifactory offers advanced proxying, caching and security facilities to
>> answer the needs of a robust, reproducible and independent build
>> environment
>> using Maven 2.
>> It uses a JSR-170 Java Content Repository (JCR) for storage, which makes
>> it
>> extremely easy to manage searchable metadata, and provide extended
>> features
>> such as security, transacted operations, auditing, locking, etc.
>>
>> Artifactory is distributed under APLv2 at
>> http://artifactory.sourceforge.net.
>> It is currently available as a downloadable archive, that can be run out
>> of
>> the box (with default settings). An install script to run it as a Linux
>> service is also provided.
>> A (limited) guest live demo is available at
>> http://www.jfrog.org/artifactory/
>>
>> You are welcome to give it a go!
>>
>> Cheers,
>>
>> Yoav Landman,
>> The Artifactory Team
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-ANN--Artifactory---new-Maven-2-proxy-repository-tf3344299s177.html#a9301347
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-ANN--Artifactory---new-Maven-2-proxy-repository-tf3344299s177.html#a9305322
Sent from the Maven - Users mailing list archive at Nabble.com.


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

[ANN] Artifactory - new Maven 2 proxy repository

[Yoav Landman]

Hi all,

We would like to announce the immediate availability of Artifactory, a Maven
2 enterprise proxy.

Artifactory offers advanced proxying, caching and security facilities to
answer the needs of a robust, reproducible and independent build environment
using Maven 2.
It uses a JSR-170 Java Content Repository (JCR) for storage, which makes it
extremely easy to manage searchable metadata, and provide extended features
such as security, transacted operations, auditing, locking, etc.

Artifactory is distributed under APLv2 at
http://artifactory.sourceforge.net.
It is currently available as a downloadable archive, that can be run out of
the box (with default settings). An install script to run it as a Linux
service is also provided.
A (limited) guest live demo is available at
http://www.jfrog.org/artifactory/

You are welcome to give it a go!

Cheers,

Yoav Landman,
The Artifactory Team

-- 
View this message in context: 
http://www.nabble.com/-ANN--Artifactory---new-Maven-2-proxy-repository-tf3344299s177.html#a9301347
Sent from the Maven - Users mailing list archive at Nabble.com.


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