Any way to ignore LayoutExceptions?
I've deployed an artifact that does not have the same name as its parent module (long story) and I can't retrieve it, getting this exception: org.apache.maven.archiva.repository.layout.LayoutException: Invalid path to Artifact: filename format is invalid, should start with artifactId as stated in path. Is there any way I can prevent Archiva from enforcing this restriction? Thanks, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Archiva selectively failing to proxy one particular artifact
How/where/what are the options to manipulate Archiva logging? It's on Windoze, probably not a permissions problem... I haven't done anything special to that particular directory, and there are scores of other artifacts being proxied and served without issue. Just one day Maven started requesting the 2.0.6 pom for whatever reason, and Archiva refused to proxy that artifact (and only that artifact). Archiva also proxied successfully the Maven pom for 2.0.5 or 2.0.7 (which was requested by Maven 2.0.8 for reasons known only to itself, which I'll need to investigate later). -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:16 PM To: [EMAIL PROTECTED] Subject: Re: Archiva selectively failing to proxy one particular artifact what about permissions problems? anything in the logs (may need to turn up the level a bit)? The other thought is whether the database has something in it that causes it not to work, but I don't think it's consulted first. I'm out of other ideas... really quite strange. - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: It populates just an empty 2.0.6 directory. The behavior is the same whether that dir is pre-existing or not. I guess I could try installing that artifact by hand and see what happens. I've also tried restarting tomcat as well. I'm not sure how I might go about restoring the state other than that. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 4:45 PM To: [EMAIL PROTECTED] Subject: Re: Archiva selectively failing to proxy one particular artifact it works for me, so there must be a state problem rather than a bug in the proxying related to that artifact. Do you have any content for that version in the managed repository? - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.po m Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/ - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Archiva selectively failing to proxy one particular artifact
OK thanks, I figured out what's going on. The checksum was failing for http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.6/maven-2.0.6.p om Testing confirms that it seems the checksums in the central repo are wrong. I manually ran md5 and sha1 sums on that file, and they do not match the sums stored in central. By comparison, the pom for 2.0.7 does not have this problem. Having confirmed this, if I could beg your indulgence for a couple of followup questions: 1) You said you didn't have this problem... I presume you have checksumming set to 'ignore' or 'fix' in Archiva? 2) Is a 404 really the only error we get on this problem? This is the same thing you'd get for a completely nonexistent artifact, it's kind of misleading. 3) (Rhetorical question) WTF is up with Maven central having bad checksums for Maven's own artifacts, and how can I be the first one to notice this? Did I make some mistake, or is everyone except me ignoring checksums? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 10:49 AM To: [EMAIL PROTECTED] Subject: Re: Archiva selectively failing to proxy one particular artifact the log configuration files are in /apps/archiva/webapp/WEB-INF/classes/log4j.xml On 01/03/2008, Brown, Carlton [EMAIL PROTECTED] wrote: How/where/what are the options to manipulate Archiva logging? It's on Windoze, probably not a permissions problem... I haven't done anything special to that particular directory, and there are scores of other artifacts being proxied and served without issue. Just one day Maven started requesting the 2.0.6 pom for whatever reason, and Archiva refused to proxy that artifact (and only that artifact). Archiva also proxied successfully the Maven pom for 2.0.5 or 2.0.7 (which was requested by Maven 2.0.8 for reasons known only to itself, which I'll need to investigate later). -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 5:16 PM To: [EMAIL PROTECTED] Subject: Re: Archiva selectively failing to proxy one particular artifact what about permissions problems? anything in the logs (may need to turn up the level a bit)? The other thought is whether the database has something in it that causes it not to work, but I don't think it's consulted first. I'm out of other ideas... really quite strange. - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: It populates just an empty 2.0.6 directory. The behavior is the same whether that dir is pre-existing or not. I guess I could try installing that artifact by hand and see what happens. I've also tried restarting tomcat as well. I'm not sure how I might go about restoring the state other than that. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED]Sent: Thursday, February 28, 2008 4:45 PMTo: [EMAIL PROTECTED]Subject: Re: Archiva selectively failing to proxy one particular artifact it works for me, so there must be a state problem rather than a bug in the proxying related to that artifact. Do you have any content for that version in the managed repository? - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.po m Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance
Archiva selectively failing to proxy one particular artifact
I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Archiva selectively failing to proxy one particular artifact
It populates just an empty 2.0.6 directory. The behavior is the same whether that dir is pre-existing or not. I guess I could try installing that artifact by hand and see what happens. I've also tried restarting tomcat as well. I'm not sure how I might go about restoring the state other than that. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 4:45 PM To: archiva-users@maven.apache.org Subject: Re: Archiva selectively failing to proxy one particular artifact it works for me, so there must be a state problem rather than a bug in the proxying related to that artifact. Do you have any content for that version in the managed repository? - Brett On 29/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: I have a strange problem where an Archiva instance absolutely refuses to retrieve one particular artifact from central under any circumstances... it is /org/apache/maven/maven/2.0.6/maven-2.0.6.pom . I've verified that the instance can retrieve other artifacts, in fact maven-2.0.5.pom retrieves just fine, as well as other randomly selected jars and pom files. It's only maven-2.0.6.pom that it fails on. I also verified that the file is in fact on maven central. When I say I'm testing it, I mean that I'm pointing a browser to the archiva URL designating an artifact that is not yet proxied, for example http://myarchivahost/archiva/repository/myrepo/org/apache/maven/2.0.6/ ma ven-2.0.6.pom which returns a 404 error message. Also, I don't know if this is related or not, but the 404 message displays a munged, invalid URL: The following resource does not exist: http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.pom http://myarchivahost/repository/org/apache/maven/2.0.6/maven-2.0.6.po m Notice that the the context string archiva doesn't appear in the displayed URL, and neither does the repository name myrepo. But since this behavior is reproducible with other well-formed URL's for nonexistent artifacts, this may not be related to my problem at all. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/
How to set username/password on a mirror?
How do you configure Maven to supply a username/password to a mirror that expects it? I've configured Maven to route all its requests through our internal Archiva proxy by setting the proxy as mirrorOf * as is usually done: mirror idourcorp-internal/id urlhttp://repo.ourcorp.com/archiva/repository/m2-central-cached//url mirrorOf*/mirrorOf /mirror The problem is, Archiva is returning 401 access denied.* I get a username/password prompt when I plug this URL into a browser, so I guess Archiva expects Maven to pass these credentials, but where am I supposed to declare them in the Maven config? I searched the settings docs, but they have nothing to say about this situation (at least the docs I found). Advice or alternate workaround config appreciated, thanks in advance... * You might ask, how can I be so certain it's a 401 error when the Maven error message shows no details of connection failures? I used a packet sniffer. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Derby database relative to `cwd` ?
In my latest Archiva installation, I noticed that Archiva resolves the
path to the derby database relative to whatever was the current working
directory at the time Tomcat was started.
For example, if I'm in $CATALINA_HOME/bin and I run ./catalina.sh start,
then the derby database gets created under
$CATALINA_HOME/bin/archiva/derbydb.If I restart Tomcat later from a
different directory, it gets created from scratch in that different
directory.
To work around this issue and make sure the derby db dir is always
resolved to the same place, before Tomcat starts in catalina.sh, I must
explicitly call: cd $CATALINA_HOME
Here's part of my archiva.xml, where the path to the derby db gets set:
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
username=sa
password=
driverClassName=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:archiva/derbydb;create=true /
And in catalina.properties I have this:
appserver.home=${catalina.home}
appserver.base=${catalina.home}/archiva
This is Archiva 1.0.1 on Tomcat 6.0.16 with JDK 1.6.0_04, RHEL 5
Thanks in advance,
Carlton
-
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
RE: Best practice to represent an arbitrary collection of jars asa single dependency?
Yes, we have a similar problem, not RAD but something like it. Your solution below is more or less what I figure I'll have to do. It's a variation on the other solutions mentioned, but it helps clear things up for me. So if I'm reading below correctly, you're essentially ignoring the real version of the artifact and mapping them all as version 6.3.9 (which is presumably the version of RAD you're using)? If the virtual POM specifies a master version of (for example 6.3.9), I guess one could install all the individual jars with their actual version numbers (derived from the jar filename or manifest). It's just a small additional effort if I've decided to throw in the towel and script a mass install. Question: I notice that using dotted notation in groupId expands to a directory structure during installation or deployment. Does this behavior also hold for artifactId? -Original Message- From: Olivier Dehon [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 9:48 PM To: Maven Users List Subject: Re: Best practice to represent an arbitrary collection of jars asa single dependency? I had to resolve a similar issue when trying to compile RAD projects with Maven. RAD comes with WebSphere runtime JARs in a specific directory (which would be provided on the WebSphere server). By default, RAD uses those runtime libraries without the need to specify the dependency in the .classpath explicitly (RAD defines the concept of a container for that purpose). To be able to build the RAD project with Maven, I uploaded all of the runtime JARs as artifacts in my repository, and created a dependency-only pom project that has all those dependencies. Then, to build the project with Maven, I simply have to add a dependency on that pom project, and set it as provided scope to emulate in Maven the RAD build environment. Once the project compiles ok, running mvn dependency:analyze helps trimming down those provided dependencies to only the ones that are actually needed. Uploading all jars from a directory to the repository is actually a very easily scriptable task with a decent shell, if you are installing the JARs with the same groupId and version for all of them. For example (untested, but you get the idea): for lib in *.jar; do artifact=`basename $lib .jar` mvn install:install-file \ -DgroupId=com.somecorp -Dversion=6.3.9 \ -DartifactId=$artifact \ -Dpackaging=jar -Dfile=$lib echo \dependency\ \artifactId\$artifact\/artifactId\ \groupId\com.somecorp\/groupId\ \version\6.3.9\/version\ \/dependency\ somecorp-meta.pom done Just edit somecorp-meta.pom after that to add header and footer and install it with install:install-file also. I hope this helps. -Olivier On Tue, 2008-02-26 at 12:41 -0600, Wayne Fay wrote: This simply is not a feature that currently exists in Maven, and for a lot of reasons, I don't see it being a feature that will be implemented any time soon. Your best bet is the list all artifacts as dependencies in a pom, and depend on it option that I suggested earlier. This in combination with Archiva, Artifactory, Proximity etc would be the right solution in my book. But, I don't think your projects actually need all 50 of those artifacts. So the best solution is to specify the proper dependencies explicitly in each project, and use a shared parent with a dependencyManagement section that helps you manage versions of artifacts. Wayne On 2/26/08, Brown, Carlton [EMAIL PROTECTED] wrote: I want to take a single directory of ~50 jars and specify that as a single dependency. I'm explicitly trying to avoid specifying them as 50 separate dependencies in a pom file, or breaking them out in 50 different module subdirectories under an internal Archiva repository. It sounded to me as if this is what you were suggesting, quite a bit of work. Perhaps I'm not wording the question correctly, as it seems like this would be a very common situation. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 11:49 AM To: Maven Users List Subject: Re: Best practice to represent an arbitrary collection of jars as a single dependency? I guess we don't understand what you want/need, as it sounds a lot like what we're suggesting. You can manage the artifacts themselves by using Archiva etc rather than asking Maven to download direct from the Internet. An alternative is to unzip each jar into a shared directory and then re-jar all of it. But I don't know if that would actually work due to log4j.xml collisions etc. Wayne On 2/26/08, Brown, Carlton [EMAIL PROTECTED] wrote: These approaches both involve resolving each jar as an individual separate dependency, a large amount of manual effort for a couple of reasons. I'd have to specify 50 new dependencies in the POM
Best practice to represent an arbitrary collection of jars as a single dependency?
Hi all, newb question here... Somewhere long ago, an internal dev project started depending on foo-corp/lib/**/* of a 3rd-party framework, which ends up being a random collection of 50 jars or so. What's the Maven best practice for representing a big bag o' jars as a single dependency? I know it would be ideal to resolve our dependency graph with greater granularity, but until someone has copious free time to do that, we'd need a simple interim solution to move us forward on the Maven track. Just to make it clear, the repository dir would look something like: /foo-corp/bigbagofjars/5.7/ And it would contain a random selection of goodies such as: apache-commons-codec_1.3.jar apache-commons-discovery_1.1.jar apache-commons-logging_1.1.jar axis-jaxrpc_1.1.jar axis-saaj_1.1.jar axis-wsdl4j_1.1.jar axis_1.1.jar bsh_1.3.0.jar jdom_b8.jar junit_3.8.1.jar ldapjdk_5.2.jar log4j_1.2.8.jar oracle_9.2.0.5.jar xalan_2.6.0.jar xerces-xml-apis_2.6.2.jar xerces_2.6.2.jar xpp3_min-1.1.3.4.I.jar xstream-1.1.3.jar If I'm missing some obvious best practice, please feel free to point it out, this is just the best I've been able to come up with so far. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice to represent an arbitrary collection of jars as a single dependency?
These approaches both involve resolving each jar as an individual separate dependency, a large amount of manual effort for a couple of reasons. I'd have to specify 50 new dependencies in the POM, and then I'd have to stage these artifacts separately in our internal repository. This jar collection is certified by our internal QA process, although some of them are probably sitting out on Maven central, we're not just going to take whatever comes off a public repository without certifying it first. So basically what I'm needing to do is specify a single dependency that is composed of 50-something arbitrary jars. I was able to do this in Ivy, I figured Maven would likewise have a way to accomplish this result. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:27 AM To: Maven Users List Subject: Re: Best practice to represent an arbitrary collection of jars as a single dependency? Just make a project with type pom and specify these dependencies. Then, depend on this project in your other projects, and it will bring in those dependencies transitively. If you're certain about those versions, you can lock them down with version[1.2.3]/version. Wayne On 2/26/08, Brown, Carlton [EMAIL PROTECTED] wrote: Hi all, newb question here... Somewhere long ago, an internal dev project started depending on foo-corp/lib/**/* of a 3rd-party framework, which ends up being a random collection of 50 jars or so. What's the Maven best practice for representing a big bag o' jars as a single dependency? I know it would be ideal to resolve our dependency graph with greater granularity, but until someone has copious free time to do that, we'd need a simple interim solution to move us forward on the Maven track. Just to make it clear, the repository dir would look something like: /foo-corp/bigbagofjars/5.7/ And it would contain a random selection of goodies such as: apache-commons-codec_1.3.jar apache-commons-discovery_1.1.jar apache-commons-logging_1.1.jar axis-jaxrpc_1.1.jar axis-saaj_1.1.jar axis-wsdl4j_1.1.jar axis_1.1.jar bsh_1.3.0.jar jdom_b8.jar junit_3.8.1.jar ldapjdk_5.2.jar log4j_1.2.8.jar oracle_9.2.0.5.jar xalan_2.6.0.jar xerces-xml-apis_2.6.2.jar xerces_2.6.2.jar xpp3_min-1.1.3.4.I.jar xstream-1.1.3.jar If I'm missing some obvious best practice, please feel free to point it out, this is just the best I've been able to come up with so far. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice to represent an arbitrary collection of jars as a single dependency?
I want to take a single directory of ~50 jars and specify that as a single dependency. I'm explicitly trying to avoid specifying them as 50 separate dependencies in a pom file, or breaking them out in 50 different module subdirectories under an internal Archiva repository. It sounded to me as if this is what you were suggesting, quite a bit of work. Perhaps I'm not wording the question correctly, as it seems like this would be a very common situation. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 11:49 AM To: Maven Users List Subject: Re: Best practice to represent an arbitrary collection of jars as a single dependency? I guess we don't understand what you want/need, as it sounds a lot like what we're suggesting. You can manage the artifacts themselves by using Archiva etc rather than asking Maven to download direct from the Internet. An alternative is to unzip each jar into a shared directory and then re-jar all of it. But I don't know if that would actually work due to log4j.xml collisions etc. Wayne On 2/26/08, Brown, Carlton [EMAIL PROTECTED] wrote: These approaches both involve resolving each jar as an individual separate dependency, a large amount of manual effort for a couple of reasons. I'd have to specify 50 new dependencies in the POM, and then I'd have to stage these artifacts separately in our internal repository. This jar collection is certified by our internal QA process, although some of them are probably sitting out on Maven central, we're not just going to take whatever comes off a public repository without certifying it first. So basically what I'm needing to do is specify a single dependency that is composed of 50-something arbitrary jars. I was able to do this in Ivy, I figured Maven would likewise have a way to accomplish this result. -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:27 AM To: Maven Users List Subject: Re: Best practice to represent an arbitrary collection of jars as a single dependency? Just make a project with type pom and specify these dependencies. Then, depend on this project in your other projects, and it will bring in those dependencies transitively. If you're certain about those versions, you can lock them down with version[1.2.3]/version. Wayne On 2/26/08, Brown, Carlton [EMAIL PROTECTED] wrote: Hi all, newb question here... Somewhere long ago, an internal dev project started depending on foo-corp/lib/**/* of a 3rd-party framework, which ends up being a random collection of 50 jars or so. What's the Maven best practice for representing a big bag o' jars as a single dependency? I know it would be ideal to resolve our dependency graph with greater granularity, but until someone has copious free time to do that, we'd need a simple interim solution to move us forward on the Maven track. Just to make it clear, the repository dir would look something like: /foo-corp/bigbagofjars/5.7/ And it would contain a random selection of goodies such as: apache-commons-codec_1.3.jar apache-commons-discovery_1.1.jar apache-commons-logging_1.1.jar axis-jaxrpc_1.1.jar axis-saaj_1.1.jar axis-wsdl4j_1.1.jar axis_1.1.jar bsh_1.3.0.jar jdom_b8.jar junit_3.8.1.jar ldapjdk_5.2.jar log4j_1.2.8.jar oracle_9.2.0.5.jar xalan_2.6.0.jar xerces-xml-apis_2.6.2.jar xerces_2.6.2.jar xpp3_min-1.1.3.4.I.jar xstream-1.1.3.jar If I'm missing some obvious best practice, please feel free to point it out, this is just the best I've been able to come up with so far. Thanks in advance... - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: Archiva crashes after a couple of days
-Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 4:07 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days I too had this same issue. Make sure your cron syntax is correct as it is not standard unix cron syntax. The first entry is a second number, not minutes. I initially (and accidentally) setup our cron jobs to run at a crazy pace, I think every second. Me three. I didn't see any reason not to scan every minute, but in fact it was every second. Result - massive log files, Archiva hung. Did not have to reinstall it, though. The cron setup would be a good candidate for improved input forms and/or validation. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Reverse artifact lookup?
Hi all, This question may in fact be generalized to Maven, but I'm wondering if there is any reverse lookup mechanism for jar artifacts. For example, I have this mystery dependency called foo.jar. Is there a way to query a Maven-compliant repository to search on the checksum to determine the group, module, revision, etc? I think Archiva has this feature, but could it proxy such a query to the Maven 2 repository? Thanks, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Artifacts not being indexed
Hi, I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. How can I troubleshoot this problem and determine whether it's the database failing to pick it up, or archiva failing to index it, or something else? Would there be errors written to a log somewhere? I've checked archiva.log which shows nothing except the requests for the scanning and indexing tasks. This is a frequent problem I've been having, it would be good if there were some good diagnostics for indexing problems. -Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Artifacts not being indexed
-Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 1:17 PM To: archiva-users@maven.apache.org Subject: Re: Artifacts not being indexed On Fri, Feb 15, 2008 at 11:06 AM, Brown, Carlton [EMAIL PROTECTED] wrote: I've got a problem where an artifact downloaded to the filesystem cannot be browsed. There's some problem with either the database scanning or repository indexing. The maven metadata files are not being generated. The pom file appears to be good. By downloaded, do you mean you are using Archiva as a proxy? Or do you have an external process that is writing to the filesystem? External process writing to the filesystem. The first thing I'd track down is why there is no metadata file. There is a checkbox in the Archiva config that will make it create missing metadata files. Try checking that box and then clicking 'scan' and then 'update database'. Does it now show up in browse? It does not. That checkbox appears to be enabled by default, and I have been doing 'scan' and 'update database', so no luck there. Strangely, when this happens, the artifacts show up in a search, but you can't browse to them. I mean they don't show up under the /archiva/browse URL, you can use the /repository URL and see them there just fine. (I've seen it create missing metadata files. I'm less sure about its ability to repair broken ones.) It does create missing metadata files, but the process seems to be very hit-or-miss, and shows almost nothing in the way of useful feedback or diagnostics. Is there some other, more decisive manual way to force it to re-scan the entire filesystem and recreate the metadata files? - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Exposing artifacts other than jar and pom
What component would that be under? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 4:31 PM To: [EMAIL PROTECTED] Subject: Re: Exposing artifacts other than jar and pom ok - can you make sure to file that in JIRA? Thanks, Brett On 15/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:12 AM To: [EMAIL PROTECTED] Subject: Re: Exposing artifacts other than jar and pom On 15/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: There is also a side box called Downloads which offers the pom and a jar for download. 1) Is there any way to offer artifacts for download other than a pom or a jar? It has javadocs, etc. It should work for non-jars as well. But if you want further additional things to be added to that - I'm not sure how extensible it is and would need to do some digging. I think it already should show everything it discovers - but if not that might need to be a feature request. It does not appear to show everything it discovers. I have a tar artifact that does not get exposed for download. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you. -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: Artifacts not being indexed
Actually I can think of one factor that might have contributed... I deleted that particular module off the filesystem, then updated and scanned, because I was testing something and not seeing what I thought I should see. So having cleaned it out, I published the artifact again, and it failed to appear in the browse screen. I wonder if Archiva's internal state showed that the artifact had already been indexed, therefore it detected no need to index again? I'm speaking in general terms because I don't know the internals. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Artifacts not being indexed
-Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 1:51 PM To: [EMAIL PROTECTED] Subject: Re: Artifacts not being indexed On Fri, Feb 15, 2008 at 11:31 AM, Brown, Carlton [EMAIL PROTECTED] wrote: Is there some other, more decisive manual way to force it to re-scan the entire filesystem and recreate the metadata files? Sure. Stop Archiva, and delete both the Lucene index files and the Archiva database. Look for a .index directory at the top of your repository. Delete the whole directory, not just the contents. Likewise, delete the whole directory for the Derby database, which is usually in data/archiva/database. I found a bit easier way, but I'll hang onto those other instructions. In the Archiva GUI I just deleted the repository and selected configuration only. Then I re-created it, scanned, updated. As I hoped, this time the metadata was generated and the artifacts were browse-able. Re-start, and then scan and update (in that order.) Can you explain what's the difference in scan vs. update and the reason that scan needs to be done before update? Not that I doubt you, I just want to understand the product. When you say they can't be browsed, are you seeing an error message? No error message. I just start drilling down from the top level of the 'browse' screen down into the group level, and the module does not appear in the list. I've had problems when I'm missing a parent pom in the repository. It will say it can't find the object model or some such thing. I have seen that happen when a pom was missing, malformed, or contained unexpected information. That was not the case this time. What version of Archiva are you using? Is it standalone (Plexus Appserver) or are you using the war file in Tomcat/Jetty/etc.? 1.0.1 war on Tomcat 5.5.25 Thanks - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Exposing artifacts other than jar and pom
Hi all, I have a couple of questions about artifacts that can be accessed thru the browse screen. When I browse a module in Artifactory, there's a navbar on the top with the elements info, dependencies, dependency tree, used by, mailing lists. 1) What's the purpose of mailing lists, and from whence is this information derived? 2) Is there any way to add other data to that navbar, for example an html junit report or somesuch? There is also a side box called Downloads which offers the pom and a jar for download. 1) Is there any way to offer artifacts for download other than a pom or a jar? Thanks in advance, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: Exposing artifacts other than jar and pom
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:12 AM To: [EMAIL PROTECTED] Subject: Re: Exposing artifacts other than jar and pom On 15/02/2008, Brown, Carlton [EMAIL PROTECTED] wrote: There is also a side box called Downloads which offers the pom and a jar for download. 1) Is there any way to offer artifacts for download other than a pom or a jar? It has javadocs, etc. It should work for non-jars as well. But if you want further additional things to be added to that - I'm not sure how extensible it is and would need to do some digging. I think it already should show everything it discovers - but if not that might need to be a feature request. It does not appear to show everything it discovers. I have a tar artifact that does not get exposed for download. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: cannot download from internalö repository [Viru s checked]
The very first problem I had with creating my own repository was that no user roles were assigned by default. I was getting HTTP 401 errors hidden in the output. So either you need to supply a valid username/password, or assign the Archiva guest user the appropriate security roles (observer, manager, usw.) I simply granted global observer permissions to guest. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 10:50 AM To: [EMAIL PROTECTED] Subject: cannot download from internalö repository [Virus checked] Hi all, having configured an company specific remote repository, I can not download any artifact from there. I can connect from a brower and inspect the repository. The only obvious difference is, there are just the pom and the jar, no metadata. Any ideas ? mit freundlichen Grüßen/best regards Wolfgang Schrecker MODEL-DRIVEN DESIGN demands that the model stay in lockstep with the implementation, but it allows freedom to choose any implementation that faithfully captures the meaning of the model from Eric Evans: Domain-Driven Design p. 230 -- -- Atos Worldline Processing GmbH Hahnstrasse 25 60528 Frankfurt/Main Germany Phone: +49 69/6657-1176 mailto:[EMAIL PROTECTED] http://www.atosworldline.com Geschäftsführer: Erik Munk Koefoed Aufsichtsratsvorsitzender: Didier Dhennin Sitz der Gesellschaft: Frankfurt/Main Handelsregister: Frankfurt/Main HRB 40 417 PS: Besuchen Sie am 21.02.2008 das Achte Kartenforum von Atos Worldline und B+S Card Service. Infos und Anmeldung unter http://www.kartenforum.de -- Atos Worldline Processing GmbH Hahnstraße 25 60528 Frankfurt/Main Germany Phone: +49 69/6657-1176 Fax : mailto: [EMAIL PROTECTED] http://www.atosworldline.com Geschäftsführer: Erik Munk Koefoed Aufsichtsratsvorsitzender: Didier Dhennin Sitz der Gesellschaft: Frankfurt/Main Handelsregister: Frankfurt/Main HRB 40 417 * * * * * * * * L E G A LD I S C L A I M E R * * * * * * * * This e-mail is destined for the above mentioned recipient. In case you received this e-mail by accident, we would appreciate it if you could contact the sender and delete all copies stored on your computer. Please be aware that the security and confidentiality of electronic data transmitted by e-mail is not completely guaranteed and that data may be seen, copied, downloaded or changed by third persons during transmission. Atos Origin accepts no liability for the security and confidentiality of data and documents sent by e-mail. Please make sure that all important messages will be confirmed in writing by means of a telefax or a letter. * * * * * * * * L E G A LD I S C L A I M E R * * * * * * * * - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Possible to remotely trigger a repository scan?
Hi, Is there any way to remotely trigger a repository scan? I'd like to create an Ant task to do this immediately following a build so that the published artifacts will immediately become available. Thanks - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
Browsing error - Unable to find project model
I'm getting this error unable to find project model when I browse down to a particular module, even though the POM and metadata are there, and I've force the database to rescan. What's going on and and how do I need to fix it? TIA, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
How to force a retrieval without using maven
Hi all, Is there a simple way to test whether Archiva can retrieve a certain artifact from the central maven repository without going through all the Maven client-side configuration? I was thinking just to point my browser at the Archiva repository with the URL of a non-existent artifact to see if this will force it to be retrieved from central, but this just gave me a 404 error. I am using the default internal repository and remote proxies as configured out of the box. TIA, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
using archiva as ivy repository
I am looking at the feasibility of using Archiva as an ivy repository and I'm not finding much. Does anyone have any suggestions, notes, or best practices for doing this? For a moment I thought I found a good doc at http://maven.apache.org/archiva/userguide/using-ivy.html which has the promising title of Using Repository as an Apache Ivy Repository. Unfortunately, the published content contains only the line :STUB: This is a documentation stub. Could I induce anyone to share a draft copy of that document? TIA, Carlton - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
