Re: Maven2 mirror @ netcologne
I've updated the metadata: http://repo1.maven.org/maven2/.meta/repository-metadata.xml On Mon, Jan 4, 2010 at 2:08 PM, Carlos Sanchez car...@apache.org wrote: Hi Christian, Thanks for providing the repo! Please subscribe to repo-maintain...@maven.apache.org, that's the list for repository matters. The mirrors are updated once a day, so you can reduce the frequency of your sync. Cheers On Fri, Jan 1, 2010 at 2:51 AM, Christian Rohmann crohm...@netcologne.de wrote: Hello again, I wrote you in march (see attached email) aber setting up a maven2 mirror in Germany. Unfortunately I never heard back from you. The official repo is rather slow when accessed from Germany (due to small many files and latency I guess), maybe we could help out with our mirror here. If you are interested in the offer, please feel free to list us with the other official mirrors. Happy New Year and Regards from Germany, -- Christian Rohmann Content Delivery Server u. Dienste Network Engineering Design NETCOLOGNE Gesellschaft für Telekommunikation mbH Am Coloneum 9 | 50829 Köln Tel: 0221 -5751 | Fax: 0221 -75751 http://www.netcologne.de Geschäftsführer: Werner Hanf Dipl.-Ing. Karl-Heinz Zankel HRB 25580, AG Köln -- Forwarded message -- From: Mirror-Service mirror-serv...@netcologne.de To: ...@maven.apache.org Date: Thu, 05 Mar 2009 09:10:56 +0100 Subject: Maven2 mirror @ netcologne Hello Maven Dev-Team, we would love to setup a mirror of the maven2 repository in Germany. As there are currently no mirrors in Germany at all, and only two danish mirrors in europe. The NetCologne GmbH is a local ISP in the greater Cologne area. Our machine mirror.netcologne.de currently runs on this hardware: 2x 3Ghz Intel Xeon CPU 2 GB RAM (to be upgraded to 4GB) 3 TB of mirror storage total The machine currently already mirrors a few linux distros (mainly debian) and other free software projects. Regarding internet connectivity, the machine itself has 2 Gigabit/s uplink. Our backbone is then connected to all major peering points in europe (DECIX, AMSIX, LINX) with 20 Gbit/s each. We are also peering in the US (2x EQUINIX) and maintain quite a few private peering with other ISPs including Deutsche Telekom (DTAG) and the DFN (Deutsches Forschungsnetz, the German university network). IPv6 connectivity is coming very soon, so mark that as checked. We configured the rsync to sync with: mirrors.ibiblio.org::maven2 every two hours in the 42nd minute. Please let me know if that's ok, or if we need to adjust that. The repo is already available on [rsync|ftp|http]://mirror.netcologne.de/maven2 If you need to contact me, just mail to crohm...@netcologne.de, as official contact for the mirror use mirror-serv...@netcologne.de. -- Mit freundlichen Grüßen Christian Rohmann --- Network Engineering and Design Tel.: +49 221 -5751 Fax.: +49 221 -75751 NetCologne Gesellschaft für Telekommunikation mbH Am Coloneum 9 50829 Köln Geschäftsführer: Werner Hanf, Karl- Heinz Zankel, Dipl. Ing. HRB 25580, AG Köln www.netcologne.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven Plugin Development - IT with Maven Invoker
Hi,
during my development of a Maven Plugin i came to point where I'm a little
but confused...
I've written an integration test for the plugin (Reporting Plugin)...
But now i got the following message during my integration-test:
[INFO] [site:site {execution: default-site}]
[INFO] artifact org.apache.maven.skins:maven-default-skin: checking for
updates from local.central
[INFO] artifact org.apache.maven.skins:maven-default-skin: checking for
updates from central
[WARNING] repository metadata for: 'artifact
org.apache.maven.skins:maven-default-skin' could not be retrieved from
repository: central due to an error: Error transferring file: Connection
timed out
[INFO] Repository 'central' will be blacklisted
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] SiteToolException: ArtifactNotFoundException: The skin does not
exist: Unable to determine the release version
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.skins
-DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.skins
-DartifactId=maven-default-skin -Dversion=RELEASE -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
org.apache.maven.skins:maven-default-skin:jar:RELEASE
Does exist a way to suppress the update check ...I've already tried to set
the --no-plugin-updates in the invoker.properties file (invoker.mavenOpts =
--no-plugin-updates) but this doesn't change anything...
Does some has a suggestion or a hint to solve this problem? May be i
oversight something or misunderstand a things...
Many thanks in advance.
Kind regards
Karl Heinz Marbaise
--
View this message in context:
http://old.nabble.com/Maven-Plugin-Development---IT-with-Maven-Invoker-tp27026579p27026579.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Plugin Development - IT with Maven Invoker
Karl Heinz Marbaise wrote: Does exist a way to suppress the update check Sure, specify the version of the skin in the site descriptor as illustrated in [0]. Benjamin [0] http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Junit
I make the occasional submissions to the junit project, and I wanted to submit a pom.xml that'd convert it into a proper maven project. My real question is what/if anything should be done to the groupId of junit. it should probably be org.junit but has since the beginning of time been just junit. I know at least surefire would need to be updated if the artifact id changed. I thought I'd put something into the pom.xml I submit to them, I'm just not sure what.. I don't know who actually publishes junit to the repos, but 4.8 and 4.8.1 have been released. If you vote for the following junit issue we might be able to make them release 4.9 themselves; http://github.com/KentBeck/junit/issues#issue/66 Kristian
WAR plugin and class file handling (archiveClasses and attachClasses options)
Hi all, I have a couple of issues with the current WAR plugin and the way it packages class files in JAR files (archiveClasses and attachClasses configuration options), as these two options work independently of each other: * archiveClasses moves all class files (and related resources) from classes directory to JAR file inside WEB-INF/lib directory * attachClasses creates a new JAR file in target directory from same set of files and attaches it to the Maven project with some qualifier (by default it uses classes qualifier) When we deploy artifacts to Maven repository, this results in two different JAR files being deployed: one inside WAR and the other separate from WAR. Problems with this approach: * two different JAR files with different MD5/SHA1 checksums. * the naming convention for these two JAR files is different These issues really start to snag you when you need to perform updates after the initial deploy of the WAR. Consider the following scenario: * development team hands WAR artifact over to deployment team for deployment * development team needs to give an update to the webapp code (the dependencies have not changed). One approach is to give the whole WAR again, but a more reasonable approach would be to give only JAR file, as it contains all the changes and dependent JARs have not changed. Whole-WAR-approach becomes especially problematic, when the update needs to be uploaded over slow network links and you are in a hurry. However, giving only JAR file presents us with some problems: 1. there is no easy way to check the currently deployed webapp JAR version, as the checksum of the embedded JAR file does not match any other JAR file in the Maven repository. 2. as the naming convention differs, it is going to confuse the deployment team Solution to this mess? Unify the way archiveClasses and attachClasses functionalities work, so they would operate on the same JAR file. The way this would work: * if archiveClasses option is specified, it moves all class files to JAR file inside WEB-INF/lib directory (same as before). It would use the same naming convention as regular Maven JAR artifacts, with some qualifier. * if attachClasses option is specified, it attaches that same JAR file (as created in previous point) to the Maven project. * if attachClasses is specified, but no archiveClasses - nothing happens. Or maybe we should then implicitly turn on also the archiveClasses option? This has some implications for backwards compatibility: * naming convention of the embedded JAR file is changed * the attached JAR file is no longer created in the target directory, next to the WAR file (it is now attached directly from WEB-INF/lib directory) I have patched the WAR plugin to have this behavior and I'm looking for feedback. Is this behavior OK or should it be more backwards compatible? If it should be more backwards compatible, then how? New configuration option? If this behavior is OK, then how do I proceed? File a new JIRA issue, with patches? Rgds, Neeme - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Plugin Development - IT with Maven Invoker
Hi Benjamin, Does exist a way to suppress the update check Sure, specify the version of the skin in the site descriptor as illustrated in [0]. Sometimes it's very simple...thanks... But...there is coming up a question about this...doesn't that mean that the dependency has mentioned somewhere else without version ? (As i understand that could be a reason for an up-to-date check)... Kind regards Karl Heinz Marbaise -- MfG Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Junit
On Tue, Jan 5, 2010 at 7:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I make the occasional submissions to the junit project, and I wanted to submit a pom.xml that'd convert it into a proper maven project. My real question is what/if anything should be done to the groupId of junit. it should probably be org.junit but has since the beginning of time been just junit. I know at least surefire would need to be updated if the artifact id changed. I thought I'd put something into the pom.xml I submit to them, I'm just not sure what.. I guess you mean adding a relocation element to their 'old' pom? http://maven.apache.org/pom.html#Relocation I don't know who actually publishes junit to the repos, but 4.8 and 4.8.1 have been released. If you vote for the following junit issue we might be able to make them release 4.9 themselves; http://github.com/KentBeck/junit/issues#issue/66 Kristian
Re: Junit
On Tue, Jan 5, 2010 at 9:15 AM, Peter Lynch pe...@peterlynch.ca wrote: On Tue, Jan 5, 2010 at 7:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: it should probably be org.junit but has since the beginning of time been just junit. I know at least surefire would need to be updated if the artifact id changed. I thought I'd put something into the pom.xml I submit to them, I'm just not sure what.. I guess you mean adding a relocation element to their 'old' pom? http://maven.apache.org/pom.html#Relocation I think the problem Kristian is identifying is that the junit:junit group and artifact ids are hard-coded in the SurefirePlugin class. Relocation won't help with this AFAICT. Justin
Re: Junit
Justin Edelson wrote: I think the problem Kristian is identifying is that the junit:junit group and artifact ids are hard-coded in the SurefirePlugin class. Relocation won't help with this AFAICT. It's already configurable [0] and could probably be extended to recognize the new ids by default as well in future versions. Benjamin [0] http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#junitArtifactName - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Commit access for Kristian Rosenvold
Ok, I'll consider this decided and get the CLA in and the account request made. On 2010-01-04, at 2:47 AM, Jason van Zyl wrote: Hi, I have reviewed the patches for the parallel build support and I think they are great. I think we should just give Kristian access to work with Dan and other developers who want to support this work. +1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Testing Kristian's MNG-3004 branch
1) I'm encountering some integration failures in my build at work when using -Dmaven.threads.experimental=1; I'll try to turn them into proper bugs in the next few days. 2) In the documentation on http://github.com/krosenvold/maven3/ it says that it does not yet build Maven 3. Does this mean that it's unable to build Maven 3 in multithreaded mode? It seems to build OK for me in non-multithreaded mode. 3) I noticed that the branch seems to be unable to run mvn eclipse:eclipse on itself; the Apache Maven 3.x project is marked SUCCESS but then all the subsequent projects are skipped. Is this known? I filed it as http://github.com/krosenvold/maven3/issues/#issue/2 4) A point of terminology: I think the branch is now using the term weave mode differently from the way I'd meant it when I introduced the term. As I understood it, weave mode means running compile X compile Y compile Z, then test X test Y test Z, as opposed to the default non-weave behavior to compile X and test X, then compile Y and test Y, then compile Z and test Z. Is that what you think it means? Or is that what violate lifecycle means? It seems like the branch uses weave mode to refer to any multithreaded build, which means that it's now not possible in Kristian's branch to do the coarse-grained multithreading I had working in my MNG-3004 branch. Do I understand that correctly? -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
