wagon jar groupId -- why org.apache.maven?
I noticed that the Maven Wagon JARs that are depended upon by such things as the artifact plugin belong to the groupId org.apache.maven.wagon. Is this the new standard for naming groupIds? What was the rationale for changing this, and are other Apache projects doing the same? - Julian -- -- Julian C. Dunn, P.Eng. [EMAIL PROTECTED] [EMAIL PROTECTED] -- Platform Administrator, CBC.ca Production Operations -- Office: 2C310-Q * Tel.: (416) 205-3311 x5592 * Fax: (416) 205-7539 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wagon jar groupId -- why org.apache.maven?
On Thu, 2005-09-22 at 21:52 +0200, Trygve Laugstøl wrote: On Thu, 2005-09-22 at 09:58 -0400, Julian C. Dunn wrote: I noticed that the Maven Wagon JARs that are depended upon by such things as the artifact plugin belong to the groupId org.apache.maven.wagon. Is this the new standard for naming groupIds? What was the rationale for changing this, and are other Apache projects doing the same? As far as I can remember that has been the group id since we started building Wagon and SCM with Maven 2. The new more verbose naming convention was needed to make it easier to organize the artifacts (and as a side-effect it gives Ibiblio some help in that the index page won't list nearly as much directories :) Hopefully most people and projects (include the Apache ones) will see the benefits of this new layout and start using it. I've already seen quite a few projects that's using the new naming convention [1,2] [1]: http://www.ibiblio.org/maven2/org/ [1]: http://www.ibiblio.org/maven2/net/ Ok, fair enough... just so I have this straight, the wagon artifacts compatible with a Maven 1 repository would reside under: repo-root/org.apache.maven.wagon/something.jar whereas with a Maven 2 repository would now be: repo-root/org/apache/maven/wagon/something.jar? So Maven 1 and 2 repos are supposed to be incompatible, right? - Julian -- -- Julian C. Dunn, P.Eng. [EMAIL PROTECTED] [EMAIL PROTECTED] -- Platform Administrator, CBC.ca Production Operations -- Office: 2C310-Q * Tel.: (416) 205-3311 x5592 * Fax: (416) 205-7539 signature.asc Description: This is a digitally signed message part
multiproject of multiprojects site generation - infinite loop
I know (from reading the list archives) that the Multiproject plugin
doesn't support multiproject nesting. From my understanding if one has a
project structure like:
projectA
\
projectB
\
- projectC1
|
- projectC2
and you try to run maven multiproject:site from projectA, it will
invoke maven site in projectB instead of maven multiproject:site.
So I tried to override projectB's site goal in the maven.xml with this:
goal name=site
attainGoal name=multiproject:site/
/goal
However, this causes an infinite loop. This is an example of the
transcript:
Starting the reactor...
Our processing order:
projectB1
projectB2
+
| Generating site for projectB1
| Memory: 3M/4M
+
multiproject:site-init:
multiproject:site:
build:start:
site:
.
.
.
multiproject:projects-init:
[echo] Gathering project list
Starting the reactor...
Our processing order:
projectC1
projectC2
+
| Generating site for projectC1
| Memory: 16M/24M
+
multiproject:site-init:
multiproject:site:
build:start:
.
.
.
+
| Generating site for projectC2
| Memory: 30M/36M
+
.
.
.
build:end:
[echo] Now building reactor projects: [projectC1, projectC2]
.
.
Our processing order:
projectC1
projectC2
and over and over.
Is there any way to get this to work?
- Julian
--
-- Julian C. Dunn, B.A.Sc, P.Eng. [EMAIL PROTECTED]
-- Platform Administrator, CBC.ca Production Operations
-- Office: 2C310-Q * Tel.: (416) 205-3311 x5592
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
working around invalid text in CVS commit messages
Some of our developers periodically check in code and write CVS commit messages containing invalid characters. For example, people will put in Ctrl-V+C accidentally, which causes our continuous build to fail with: BUILD FAILED File.. /home/jdunn/.maven/cache/maven-xdoc-plugin-1.8/plugin.jelly Element... x:parse Line.. 120 Column 48 Error on line 12 of document file:/home/jdunn/devel/util/target/changelog.xml :An invalid XML character (Unicode: 0x16) was found in the CDATA section. Nestedexception: An invalid XML character (Unicode: 0x16) was found in the CDATA section. Total time: 19 seconds Finished at: Fri Jan 28 16:55:21 EST 2005 Short of filtering this stuff out on check-in, is there any way to make Maven ignore invalid characters in the SCM history? - Julian -- -- Julian C. Dunn, B.A.Sc, P.Eng. [EMAIL PROTECTED] -- Platform Administrator, CBC.ca Production Operations -- Office: 2C310-Q * Tel.: (416) 205-3311 x5592 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven will not switch remote respository !!!????
On Thu, 9 Sep 2004, Eric Chow wrote: maven.repo.remote = http://www.bluesunrise.com/maven/, http://www.ibiblio.org/maven/, http://dist.codehaus.org/, http://cvs.apache.org/repository; snip Is there any problem ??? I might be totally off on this, but try to not put a space between the URLs of the repos? - Julian -- Julian C. Dunn [EMAIL PROTECTED] [EMAIL PROTECTED] Software Developer, CBC.ca Production Operations Office: 2C310-I * Tel.: (416)-205-5592 PGP Key: 0xDA6A5B30 [7DCD A0C3 8B6F 6A76 F4CD 9F9B F941 A1B2 DA6A 5B30] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jar help
On Fri, 2004-06-11 at 14:32, Bielby, Randy J wrote: I have a situation that I don't believe is unique but I can't seem to find all the info I'm looking for. I have several projects with a number of dependent jars. The development team is anywhere from 10-30 developers depending upon the project. We are using WSAD and have as one of the projects in our workspace a webapp. This webapp contains all the dependent jars within the WEB-INF/lib folder. All the other project within the workspace are included as dependent jars in the EAR. I would prefer that the compile uses the jars in the lib folder. This is the ensure that the deployed runtime code is the same as what the developers have developed against. I know this goes against Maven's perferred method of retrieving dependencies for the repository. I know that I can override this behavior, but I'm struggling with how to go about it. Could you override the dependency retrieving by setting maven.jar.override=true in your project.properties and then listing the path to each of the JARs explicitly? In this case, the structure does not have to respect the regular repo structure since you're not overriding maven.repo.remote. Also, due to corporate defined standards, my jar names cannot contain the version number (don't ask). So I also need my jar dependencies to be something like, log4j.jar instead of log4j-1.2.6.jar. I have tried eliminating the version from the dependency but I get, log4j-.jar instead. If you use the jar tag you can specify the filename explicitly. - Julian -- Julian C. Dunn, B.A.Sc. [EMAIL PROTECTED] Software Developer, CBC New Media Operations Office: 2C310-I * Tel.: (416) 205-3311 x5592 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: failover for maven repository?
On Wed, 2004-06-09 at 02:10, Jason van Zyl wrote: On Wed, 2004-06-09 at 00:11, Julian C. Dunn wrote: Well, we all hope that nobody mucks up the repository, but that only gets you so far -- all you have to do is to ask the Debian or FSF maintainers whose sites got cracked how far hope gets you. Yes, I'm well aware. It's not like I'm floating along in la-la land. But I don't have infinite time and I tackle what I can as does anyone else contributing to maven. Understood. I just took exception to your remark that security is a bogey man when, in fact, there have been demonstrated instances of people (script kiddies and otherwise) breaking into repository servers and wreaking all manner of havoc. In my mind, the correct approach as suggested by Casey, Pryce et al. is to store the MD5 or SHA1 checksums offline, i.e. not in the same place the JARs themselves, and then to to transfer those securely. This is basically the approach used by the FreeBSD ports system or NetBSD pkgsrc. The actual transfer of the JARs need not be secure as long as the checksums are trustworthy. If you would like to expand on that and make a little doc with some references I will happily add it to the wiki material that exists there already. Sure. My document is attached as a text file. - Julian -- Julian C. Dunn, B.A.Sc. [EMAIL PROTECTED] Software Developer, CBC New Media Operations Office: 2C310-I * Tel.: (416) 205-3311 x5592 A number of key security issues have been identified in the way Maven resolves and retrieves dependencies. These issues have been identified in documents written by Nat Pryce and John Casey: http://docs.codehaus.org/display/MAVEN/Repository+-+Security http://docs.codehaus.org/display/MAVEN/Repository+-+Security+by+nat+pryce Casey proposes to tighten up the repository upload procedure, which is a good first step. However, signing all artifacts (and in particular, the ongoing workload of needing to distribute derivative certificates) may prove to be too onerous a procedure. Pryce proposes an reasonable solution from a security perspective: storing JAR signatures in the repository as well. Presumably users would then obtain the public keys of the signers through some non-Maven means. However, whether this would actually happen is a matter of discussion. My suspicion is that most people (aside from the truly paranoid) don't even do this for the code they download from the main Apache repository, e.g httpd. A solution that I propose is to adopt the model taken by both the FreeBSD and NetBSD projects for their software packaging. In the ports (FreeBSD) or pkgsrc (NetBSD) systems, the checksums and sizes of the source tarballs are stored in a separate location, i.e. in the ports/pkgsrc CVS repository itself. Access to CVS is tightly controlled, just as it would be for the actual code itself. The checksums and sizes are transferred to the users' machines by a secure mechanism, i.e. CVS over SSH or cvsup. Adapting the model to the Maven project would entail the following: 1. Store checksums and sizes of JARs/distributions at Apache.org. Apply the same control to the checksum repo as would be kept for actual CVS commits to the code. 2. When Maven requires an artifact, it securely (e.g. over HTTPS) retrieves the size/checksum information from Apache.org. 3. It then retrieves the artifact from ibiblio. If ibiblio has been compromised, the checksum/size will not match and Maven would refuse to continue. References: --- [1] Using FreeBSD Ports: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html [2] NetBSD Pkgsrc: http://www.netbsd.org/Documentation/pkgsrc/ [3] NetBSD Pkgsrc info about 'distinfo' where checksum/size info is stored: http://www.netbsd.org/Documentation/pkgsrc/components.html#components.distinfo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
failover for maven repository?
Hello, I'm wondering if there is any way to get Maven to fail over to one or more repositories when ibiblio.org is unavailable, or does not contain the JARs that I'm looking for. It seems like the maven.repo.remote knob is an all-or-nothing deal; if I want to pull certain JARs from my local repository, I have to mirror *all* of the ibiblio JARs I want. Similarly, if I don't set maven.repo.remote to anything, I can't override one particular JAR by pointing it to a local repository; i.e. a maven.jar.foo property can only refer to a local filesystem path, not an internal repository URL. Is this a limitation of Maven, or of my understanding of how to configure it? - Julian P.S. Anyone know why xalan 2.6.0 is missing from ibiblio? -- Julian C. Dunn, B.A.Sc. [EMAIL PROTECTED] Software Developer, CBC New Media Operations Office: 2C310-I * Tel.: (416) 205-3311 x5592 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: failover for maven repository?
On Tue, 8 Jun 2004, Jerome Lacoste wrote: On Tue, 2004-06-08 at 10:11, Maczka Michal wrote: you can use: maven.repo.remote=http://repo1,http://repo2,file://repo3,http://www.ibiblio. org/maven Let me add that by precaution, you should probably always have a local repository around containing all your projects dependencies. I heard people say you shouldn't, but: - you may lose your connection - you may need to build from a place where you don't have a connection - it's always good to not be dependent on somebody else when you have to build some sotware. That's definitely my philosophy here; my sysadmins also add one more reason to that list, and it is - downloading unverified JARs from an Internet website and putting them blindly in your software is a bad idea I must admit that I share their concern; I'm curious to know whether the security implications of this have been discussed at all. - Julian -- Julian C. Dunn [EMAIL PROTECTED] [EMAIL PROTECTED] Software Developer, CBC.ca Production Operations Office: 2C310-I * Tel.: (416)-205-5592 PGP Key: 0xDA6A5B30 [7DCD A0C3 8B6F 6A76 F4CD 9F9B F941 A1B2 DA6A 5B30] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: failover for maven repository?
On Tue, 8 Jun 2004, Jason van Zyl wrote: On Tue, 2004-06-08 at 22:59, Julian C. Dunn wrote: I must admit that I share their concern; I'm curious to know whether the security implications of this have been discussed at all. Many times, we have use cases, and the upload process will become more rigourous over time. We've also had a couple more complete proposals submitted: one by Nat Pryce and one by John Casey For reference: http://docs.codehaus.org/display/MAVEN/Repository+-+Security http://docs.codehaus.org/display/MAVEN/Repository+-+Security+by+nat+pryce Those articles pretty much reflect my (and my sysadmins') concerns, thank you. Some may consider it negligence but I considered convenience to be the overriding concern. I realize security is an issue, but I feel it's become a bit a boogey man. Anything is possible and maybe there is some really, really bored guy with nothing better to do then muck up the works for everyone but I'm really hoping that doesn't happen. But in m2 we will have options for the paranoid and the upload process will be easier and more secure. Well, we all hope that nobody mucks up the repository, but that only gets you so far -- all you have to do is to ask the Debian or FSF maintainers whose sites got cracked how far hope gets you. I would rather that the Maven community take proactive steps to rectify this, rather than getting egg on our collective faces when the repo does get mangled, either by accident or on purpose. I'll give you an example of a case where even accidental repo mangling has caused us grief: commons-configuration. The JAR that is up there on ibiblio labelled 1.0-dev doesn't contain the same code as the current one (also labelled 1.0-dev) which you can download off the Jakarta site. I had a developer run across this just today: when he ran his code against what he thought was the correct 1.0-dev JAR but was in fact the old one from ibiblio, the code blew up, predictably. In my mind, the correct approach as suggested by Casey, Pryce et al. is to store the MD5 or SHA1 checksums offline, i.e. not in the same place the JARs themselves, and then to to transfer those securely. This is basically the approach used by the FreeBSD ports system or NetBSD pkgsrc. The actual transfer of the JARs need not be secure as long as the checksums are trustworthy. - Julian -- Julian C. Dunn [EMAIL PROTECTED] [EMAIL PROTECTED] Software Developer, CBC.ca Production Operations Office: 2C310-I * Tel.: (416)-205-5592 PGP Key: 0xDA6A5B30 [7DCD A0C3 8B6F 6A76 F4CD 9F9B F941 A1B2 DA6A 5B30] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
