Re: maven logo...
Hi, You can get vectorized (and a little bit fixed in typographical sense) maven logo from here: http://svn.abstracthorizon.org/proximity/trunk/proximity-site-stuff/srcs/maven-logo.svg It is SVG, was edited by Inkscape on linux, but will do any vector drawing app like Illustrator, Corel Draw or such, any that supports SVG format. Using the SVG above, you can generate bitmaps for as high res as you want :) ~t~ On Nov 22, 2007 2:31 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'm looking for a high resolution maven logo. I've found https://svn.apache.org/repos/asf/maven/site/trunk/src/site/resources/images/maventxt_logo_200.gif, but this still is a bitmap image. Who created this logo, and can the original image project be shared ? What is the charater type used in the logo ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven logo...
Hi, sure, no problem. Sorry for not obeying the rules (your disclaimer), but I had similar problem as Nicolas did, and after all, the logo is rerouted to community :) Will issue the jire as soon as i get settled :) ~t~ On Nov 23, 2007 6:20 AM, Brett Porter [EMAIL PROTECTED] wrote: We also have the original EPS in the committers area (under the Maven PMC directory). obligatory_standard_disclaimer You shouldn't use the logo without permission for making something look like it is an official part of the Maven project :) /obligatory_standard_disclaimer Also, Tamás, do you mind if we include the SVG as an alternative format? Can you submit it via JIRA? Thanks! - Brett On 22/11/2007, at 10:15 PM, nicolas de loof wrote: Thanks a lot. 2007/11/22, Tamás Cservenák [EMAIL PROTECTED]: Hi, You can get vectorized (and a little bit fixed in typographical sense) maven logo from here: http://svn.abstracthorizon.org/proximity/trunk/proximity-site- stuff/srcs/maven-logo.svg It is SVG, was edited by Inkscape on linux, but will do any vector drawing app like Illustrator, Corel Draw or such, any that supports SVG format. Using the SVG above, you can generate bitmaps for as high res as you want :) ~t~ On Nov 22, 2007 2:31 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'm looking for a high resolution maven logo. I've found https://svn.apache.org/repos/asf/maven/site/trunk/src/site/ resources/images/maventxt_logo_200.gif , but this still is a bitmap image. Who created this logo, and can the original image project be shared ? What is the charater type used in the logo ? Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, ~t~
Re: Fix missing POM files
Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned fix layers for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix something that is _obviously_ wrong. But, heh, deps are not those sort of things. ~t~ On Jan 27, 2008 6:58 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 25-Jan-08, at 5:22 PM, Carlos Sanchez wrote: great, but - who is going to enforce it? - who is going to say what the right pom is for a project that doesnt build with Maven? If someone from a project submits a POM then we should take that. If projects don't then we take a submission from the community. The base requirement should be that the complete transitive closure be available publicly and preferably in central. The new artifact resolution code will be able to do this but right now if we required correct SCM information then we could have a process grab the code and try to build it for Maven projects. Oleg can speak to some of the work in the new artifact code that can help ensure the integrity of deployments. there's still people saying that poms should be modifiable! For a release it cannot be modifiable, period. The graph cannot be mutable after a release. That has to be written in stone. If someone doesn't see something and made a mistake then they have to release again. It boils down to we get strict or this body of information we have will grow less useful over time and that's all there is to it. -- Thanks, ~t~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
Daniel, i think we talk about two things here: - to fix/modify retroactively already deployed poms and/or repo content - and i believe we both agree it is a disaster to do so. - to prevent failed download request every time the project is built. I was talking about the second problem, with corporate users in my mind. And that means, on possibly close projects in controlled environment. I completely agree with your arguments. I was just trying to give a hint for corporate users how to get rid of these failed downloads. For OSS projects/users, currently the only solution is to get people (interested maven user community) on to feet and push (demand) the affected project owners/maintainers to do something about it, to make them create deployment requests with good/valid POMs. It simply resembles me the situation to linux RPM reposes. And a solution i like from there is the disconnection (or extension) of the actual payload (project) versioning from the RPM (atifact) versioning, and the ability to republish a wrongly packaged RPM with _same_ payload but with increased full name, ie. AProject-1.0.0-1.rpm versus AProject-1.0.0-2.rpm. Actually, this is what we are talking about here, right? ~t~ On Jan 28, 2008 3:54 PM, Daniel Kulp [EMAIL PROTECTED] wrote: While I completely agree about the poms needing to be carved in stone, I really DON'T agree with the requirement to use advanced repo managers to solve problems like this. That's perfectly fine for enterprise level application development where all the developers are in the same location, but that really breaks down for open source projects where developers are all over the place, behind different firewalls, using difference repo managers that are all setup differently, etc... For example, let say I'm working on some maven plugin and I pull some new dependency. My companies repo manager is setup to fix some dependency issue in that new dependency, but I don't really know that because someone else set that up. (I'm just a developer). I build and test and everything is OK. Now you come along (or continuum, etc..) and try to build and it all fails cause your companies repo manager doesn't have that fix in place. I give the works for me response because as far as I can tell, it does work. You basically get into situations where builds are not globally reproducable. And that's a problem. That's why for companies that invest heavily in working with open source stuff, I don't recommend a repo manager and instead recommend a straight rsync or make sure the repo manager is setup as a mirror only with no additions/changes. Now, while were on the topic: obviously DEPENDENCY changes in poms are a huge problem. What are peoples thoughts on metadata changes like the licenses section, organization section, url, description, etc ? I personally feel that poms for 2.1 should REQUIRE the licenses section (either directly or inheritted from a parent) and would really like the others as well. On one hand, metadata updates usually don't break builds. On the other hand, it could make past builds not 100% reproducable if they use that metadata. (example: remote-resources) Dan On Monday 28 January 2008, Tamás Cservenák wrote: Hi, I'm with Jason here: once something is released, it should be carved into stone. The maven remote repository (every remote one, not just the central!) should only move forward in time. We cannot allow backward modification of artifacts since it may have unforeseeable consequences! Not to mention reproducibility... Anyway, if you _must_ have the missing POM (or simply want to prepare for a new fixed release that will have one, and not to litter your own project with exclusions), it is easily resolvable by some advanced repository managers like Proximity. With Proximity -- for example -- you are able easily to sneak in (or even spoof if a broken exists remotely) the missing POM by grouping a central proxy repo with with a hosted repository -- where you keep these POMs to fix central. So, you could maintain a thin layer of repos data overlayed over central repo without breaking anything. Anyway, since maven means infrastructure, it is to be expected from serious maven users to not connect directly to central (and be dependent of network outages for example) and use advanced repo managers to solve problems like this (broken deployments). Something as i see as a probable fix for situations when we are stuck (ie. the artifact is deployed wrongly but the project itself or it's staff is not interested in fixing it or are simply unreachable) is maybe to release/gather/share some sort of above mentioned fix layers for users to lay down on their MRMs and live with it. Or maybe make the deployment process more flexible, and allow repo maintainers to redeploy something -- even if it's origin project did not request it -- to fix
Re: Fix missing POM files
Heh, so you are willing to trade build reproducibility (for all projects linked to central repo) for care about the community? o.O Hrm, please put that on a vote before you do it! IF you are talking about putting up dummy (depsless, only GAV) POMs: IMHO, by putting dummy poms (without dependency to not screw existing builds), only ones with GAV, you do not provide any value to community: OSS projects usually move fast, and will quickly switch to newer (hopefully fixed) artifacts from central with correct POMs. And the companies will... heh, they will use some advanced repo manager to solve it ;D IF not, how would you be able to get authoritative data to fill in the missing POMs? Thanks, ~t~ On Jan 28, 2008 7:51 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: if there's no pom uploaded then you can take 5 minutes of your time and provide one. I try to do it for all the ones I use. It can be because you care about the community or because you are selfish and want your project to be reproducible ;) either way providing a pom doesnt take that long - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Repository Manager: Will it avoid aggregation of repositories?
Hi, Not quite. Proximity is (almost) plain HTTP proxy, but IT DOES have knowledge about maven reposes (see repository browsing or the use of ?repositoryId=central URL parameter.), but only as separate storages. What it does not have is STATE, it cannot distuingish the two consecutive HTTP GET commands from same M2, once for metadata and once for POM. The solution should be in POM (Maven). ~t~ On 7/25/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: The problem here is that Proximity is nothing but a plain HTTP proxy and has no knowledge of Maven repositories which falls apart with two repositories with the same metadata file. The first one will probably cached and the latter will never be used. So if the first repository is the snapshot repository and the latter the release repository it will probably never download the release. This is a bit disappointing as Proximity is basically what maven-proxy always has been delivering.
Re: Maven Repository Manager: Will it avoid aggregation of repositories?
Just to add: a planned feature of Proximity (awaited for RC2, but my every day job is pressing me lately) would be repository relocation. Behind the curtains, this feature would be implemented just by prefixing the repository namespace within Proximity, like: http://localhost:8080/px-webapp/repository - the current repo Px URL Lets say, you add central repo proxied from http://repo1.maven.org/maven2to px, prefixed with central, the result would be: http://localhost:8080/px-webapp/repository/central/... This way, you could shift/relocate your snapshot-able reposes with snapshot and set properly your POM/settings.xml and have separated reposes (with current M2 2.0.4!), have proxied ALL reposes and have a single proximity instance: central mirror - Px on http://localhost:8080/px-webapp/repository/central/ snapshot mirror - Px on http://localhost:8080/px-webapp/repository/snapshot/ etc. Any opinion is welcome. Thanx. ~t~ On 7/25/06, Barrie Treloar [EMAIL PROTECTED] wrote: In your pom you have specified the repository A and in your settings have configured A to point to your maven-proxy installation. Because maven-proxy aggregates the repositories the artifacts from the B and C repositories are available even though you have not defined them in your pom.
Re: Maven Repository Manager: Will it avoid aggregation of repositories?
Hi, On 7/26/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: That is not the problem, the problem is that the metadata from all the repositories has to be _merged_ and dispatched properly by proximity. That is why any plain http proxy will fail acting as a repository for Maven. Ah, I see. My knowledge was here faulty a little bit, sorry. At a first glance, it is easily implentable at proximityBean level (it has the list of repos), using some similar pattern as repositoryBean does for retrieval logic. Actually, externalize the current first serves wins serving algorithm to some customizable form. And this issue is only for aggregated reposes. Does anything else needs merging through reposes? I will create an issue for that. How can Maven solve this problem? Maven will properly merge the metadata from the different repositories but Proximity is effectively stopping half of the data coming through. sorry, i meant to say: solution could be to not aggregate repositories, you could use different base URLs for them (in POM or settings.xml). It is what Barrie suggested on the top of the thread. And it is (will be) solvable with the repo relocation i was talking about. Proximity will serve metadata properly then, no? Thanx, ~t~
Re: Maven Repository Manager: Will it avoid aggregation of repositories?
Hi, I created 3 issues: http://trac.abstracthorizon.org/proximity/ticket/3 http://trac.abstracthorizon.org/proximity/ticket/17 http://trac.abstracthorizon.org/proximity/ticket/18 and before a few days already got a ticket with similar request: http://trac.abstracthorizon.org/proximity/ticket/16 So, 3 + 16 + 17 + 18 should do it :) Thanx for help! ~t~ On 7/26/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: Tamás Cservenák wrote: Hi, On 7/26/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: That is not the problem, the problem is that the metadata from all the repositories has to be _merged_ and dispatched properly by proximity. That is why any plain http proxy will fail acting as a repository for Maven. Ah, I see. My knowledge was here faulty a little bit, sorry. At a first glance, it is easily implentable at proximityBean level (it has the list of repos), using some similar pattern as repositoryBean does for retrieval logic. Actually, externalize the current first serves wins serving algorithm to some customizable form. And this issue is only for aggregated reposes. Does anything else needs merging through reposes? Not that I can think of right now. I will create an issue for that. How can Maven solve this problem? Maven will properly merge the metadata from the different repositories but Proximity is effectively stopping half of the data coming through. sorry, i meant to say: solution could be to not aggregate repositories, you could use different base URLs for them (in POM or settings.xml). It is what Barrie suggested on the top of the thread. And it is (will be) solvable with the repo relocation i was talking about. Proximity will serve metadata properly then, no? Sounds like it. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Repository Manager: Will it avoid aggregation of repositories?
Hi, the issue is fxed and released. Please try it! The current release relies on the following solution: Repositories are divided into groups (String repo.getGroupId()). Repositories IN the same groups are merged, otherwise they are spoofed (as before). The ordering of reposes are still important, but beside repositoryOrder (list of all reposes configured independent of groupId) we have subchains by groups with same order of members. The algorithm: if we have request for non mergeable item, use who serves first -- wins by repositoryOrder. if we have request for mergable item, use who serves first -- wins to get initial copy. Then, iterate over the found item's originating repo group, and merge the result (resultlist). Thus, using current Px RC2 a solution to Barrie's inital problem would be: repo A: group A repo B: group B repo C: group C or even more sophisticated: A: group One B: group Two C: group Two So, A may be used to spoof (inhouse), but B and C (if A does not serve what it needs) will be merging metadatas. RC2 has a factory configuration as this: inhouse, group: private extFree, group: private extNonFree, group: private central, group: public All four reposes shares same repository logic, so they share newly implemented snapshot policies too: serveSnapshots=false, serverReleases=true (release is something that is not snapshot in Px vocabulary). Question: what should happen with maven-metadata.xml checksum (sha1, md5) after merge? Thanx in advance, ~t~ On 7/26/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: Tamás Cservenák wrote: Hi, On 7/26/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: That is not the problem, the problem is that the metadata from all the repositories has to be _merged_ and dispatched properly by proximity. That is why any plain http proxy will fail acting as a repository for Maven. Ah, I see. My knowledge was here faulty a little bit, sorry. At a first glance, it is easily implentable at proximityBean level (it has the list of repos), using some similar pattern as repositoryBean does for retrieval logic. Actually, externalize the current first serves wins serving algorithm to some customizable form. And this issue is only for aggregated reposes. Does anything else needs merging through reposes? Not that I can think of right now. I will create an issue for that. How can Maven solve this problem? Maven will properly merge the metadata from the different repositories but Proximity is effectively stopping half of the data coming through. sorry, i meant to say: solution could be to not aggregate repositories, you could use different base URLs for them (in POM or settings.xml). It is what Barrie suggested on the top of the thread. And it is (will be) solvable with the repo relocation i was talking about. Proximity will serve metadata properly then, no? Sounds like it. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inviting Proximity Devs to work with Maven Enterprise
Hi, The main Proximity developer is here! :) Thank you the invitation and we (at AbstractHorizon.org) think it is pretty neat idea. Proximity1 (note the 1 at the end) is in usable shape (even sorted out the issue of WebDAV and deployment) and it is very near main 1.0 release. Licensing wise, we were thinking about the final license of Proximity (and all other Abstract Horizon projects) and so far it looks like we will just go for LGPL. Hopefully that is something you can use. If not - I don't think that there will be a problem finding out some common ground or a solution for integration of Proximity to ME. Collaboration wise, your e-mail couldn't come in the better time - since Proximity is closing to the 1.0 release we have already started preparations for Proximity 2 which should be all singing and dancing version of Proximity 1 and more. Functionality of existing Proximity is going to be a bit more formalised and all these border cases are to be given as a choice to the end user. Your input into this area is going to be appreciated! Aside Proximity 2 there are some other grand ideas two of us already touched some time ago and collaboration in the area Maven is really good way forward. Who knows what else (long term of course) can come out of it :) Ok, for a start, please let us know about specifics we can be of help to you and if you had anything else in mind. Looking forward working together, Tamas, On 2/22/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I think the main Proximity developer is here, and I was wondering if you would like to work with us on Maven Enterprise (ME)? Essentially this means us putting a small wrapper around Proximity and firing it up from the ME server? I'm not sure what the licensing is on Proximity but if it's a license compatible with the ASF then we could package up Proximity with ME which I think would be very cool. I've heard good things about Proximity, and only tried it out for a week but I think you guys have done the leg work and have something that works well and we should support you instead of our meagre efforts in this area. You have made something that works and people like and I think it would be wise to incorporate it into ME if you're interested. We should be encouraging people making good Maven-based applications and I think Proximity is a perfect example. This doesn't mean moving your project anywhere, really just redistributing a binary of Proximity with some integration pieces. I am using an extended version of ME for a client which wraps a Spring application so I don't think wrapping Proximity would be any different. I honestly have a couple clients who want proxy support and they have already started looking at Proximity because maven- proxy is not supported and Archiva didn't really work. I also have some training in the near future and at ApacheCon and I'm going to be using ME or an open variant of it and so I would like to include Proximity because that's what I would like to promote in the training. I can go ahead and just make a bundle that includes Proximity for training but some official collaboration would be preferable and I think that's ultimately more beneficial to Maven users who want enterprise grade proxy support. Any of the Proximity developers care to comment? Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven's future repository support
Hi, I always looked at repo IDs as something local to my machine (take into account Brian's note: apache.snapshot vs apache.snapshots vs apache-snapshot etc). How many builds exists with those variants of the same repo? Also, you can easily pull in the _same_ repo with different ID into the build over some dependency or different profile. What then? My thought: a) if using entry level / OSS maven, the repo URL will be entered by the user anyway. b) if using enterprise level, where we can expect some control, the URL will also be added once somewhere (centrally managed settings, repoman or whatever), but we can expect that enterprise level users will/should use enterprise level tools :) Hence, the URL is the one and only thing that fulfills the HTTP adressability of repo, even if the repo is dead (absent, host is down or simply the project ceased to exist), we can keep a history/list/directory of know reposes and optionally offer some alternatives. Not saying this is a job for maven itself, mere for the maven community. And we can make tools easily that consumes those directories and makes the job. ~t~ On Mon, Mar 17, 2008 at 1:33 AM, Brian E. Fox [EMAIL PROTECTED] wrote: I think there are two mutually exclusive things : 1) in an enterprise with a repo man and 2) not So 1) If a repo manager is declared, that url is used for all lookups regardless of defined repos on settings or poms. Perhaps a translation to url like Nicolas' feature is used here for repo mans/proxies that don't provide aggregation. This should be able to be declared in a profile to enable devs to work in an enterprise/with repo man and without easily (currently it's a pain to switch back and forth) 2) This is where proxies/mirrors/repo definitions come into play. Same as above, all should be in profiles. I think that mirroring by Id isn't always the greatest, but I also see no harm in continuing to support it because it can be useful in some instances. The adhoc nature of declaring repos is annoying to be sure (I'm sure everyone has seen apache.snapshot and apache.snapshots) but I don't currently have any ideas how this can be handled better. An additional mirrorOfUrl could be added to the settings so you could use mirrors by id or by url as you see fit. It would be nice to provide some automatic geo lookup but I'm not sure how that would happen. It seems like this data needs to be stored in the repo itself and then cached in the local repo. Otherwise someone would have to provide a redirection service which isn't feasible for all repos. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, March 16, 2008 7:06 PM To: Maven Developers List Subject: Maven's future repository support Forking the other thread. Maven still needs to work properly without a repository manager (even if it is a good practice to use one). In my opinion, that means: - proper unique identifiers for repositories (my preference would actually be to control this by group ID, but I see too many counter examples in the Maven repositories to make this realistic - if anyone has ideas on this front please say so). - proper mirroring support (ie, specify which mirror you want to use for central, etc so you can get a nearby one out of the box, like CPAN, yum, etc type setups - I have some hand written notes from some time back sitting on my desk I can kick into the wiki) - full control over the repositories you use from the settings file. When it comes to handling repositories in POMs - I think they should still be in there, but only be a hint. ie, if the repo with that ID is not configured, Maven can intelligently tell you how to configure it if you want to, and the consequences of doing so. But I'm sure there are plenty of other ways we could deal with this. On top of this, explicit support for repository managers (that supports all of them) as a way to replace one or all of your repositories should be available and encouraged. Are these all the use cases folks see? - Brett -- Brett Porter [EMAIL PROTECTED] 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] -- Thanks, ~t~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring by repository id? is it still sane?
Hi all, after Nigel words, i tried to play with Nexus and HTTP Proxying and have tested some solutions with Nexus and HTTP Proxying. It seems that it is feasible and easily done. I set my m2 to use Nexus as HTTP Proxy, and made nexus to use the incoming URL as basis to resolve the repo in question. This way, i was able to do do the following: i had a clean settings, without mirrorOf, lots of repo, etc. Only one proxy elem with nexus in it. And build Nexus itself with running Nexus as HTTP Proxy :) Nexus was happy to do the thing. Also, some features I thought about: I have the full URL from request, on which i can base some decisions: Nexus can search it's own proxy reposes (matching the remote URL with request URL), do a URL prefix match (reposes cannot be nested in each another, hence repo roots should be unique) and simply serve requests from those Nexus reposes, and if a repo is not found: a) do a real HTTP proxy call reaching outer world (or better: create proxied repo automatically and use it at once -- on the fly?) b) simply block and return 404 (to simply prevent outer reach). or c), prepare proxied repo automatically as new Proxied repo. But return 404 to stop the build (it would timeout anyway if awaited too long) a), b) or c) could be some policy of Nexus. There is an issue of calculating the repo root (the full url does not says anything about repo root), but i think it is easily done, at least by some alg that will work in 90% of cases, for a start :) And this is a problem only when automating repo addition, like in case a). The b) and c) cases would probably make the build fail, but _it_does_not_ replace real Build Discovery, since it would know only about touched/needed reposes only. Repeating the build would may introduce a new unknown repo. WDYT? ~t~ On Sun, Mar 16, 2008 at 7:39 PM, Nigel Magnay [EMAIL PROTECTED] wrote: I've never thought it was sane in the first place... I don't understand why the artifact servers (archiva et al) can't just respond in the same way that an ordinary proxy server does, without all this mirrorOf mucking about. Working on two or three independant projects and my settings.xml is a bloatfest of project-specific repo names. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latency of syncs in Nexus with central
Hi there, The problem is more how is central repo in public group on our Nexus served: Central is _not_ proxied by Nexus, but is rsynced from repo1.maven.org to repository.sonatype.org, and it is served from there by Nexus as hosted repo. The problem is probably our rsync process (not [yet] fired, or something). Also, according logs, you points to at Hudson, shows that the 1.5.6 pom was there, but the jar was not. Hence, i think it is 99% the rsync. Not that this solves your failed build, just explaining what happens behind the curtains :) ~t~ On Fri, Aug 1, 2008 at 12:55 PM, Benjamin Bentmann [EMAIL PROTECTED] wrote: Hi, does the Nexus instance serving our Hudson have a certain latency with regard to catching up with central? I am wondering since CI failed [0] on maven-invoker which I updated to use the just released plexus-utils:1.5.6 [1] Benjamin [0] https://ci.sonatype.org/job/maven-shared/185/org.apache.maven.shared$maven-invoker/console [1] http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, ~t~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Decent size icon for Nexus?
Wow, this fluid thingy is really cool, to set up personal nexus humm ~t~ On Sat, Aug 9, 2008 at 6:17 PM, Jason Dillon [EMAIL PROTECTED] wrote: Um, sure its Jetty... but thats the *server* not the console, which was what I was talking about. --jason On Aug 9, 2008, at 11:10 PM, Brian E. Fox wrote: Nexus already is standalone with the built in Jettybut the Nx icon was made for the 16x16 icon size, we haven't yet made anything larger. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Saturday, August 09, 2008 1:52 AM To: Maven Developers List Subject: Re: Decent size icon for Nexus? You haven't played with Fluid yet? http://fluidapp.com/ Its pimp, lets you make a web-app into more of a standalone application. --jason On Aug 9, 2008, at 12:15 PM, Jason van Zyl wrote: I have no idea what you're talking about ... Sent from my iPhone On Aug 8, 2008, at 9:50 PM, Jason Dillon [EMAIL PROTECTED] wrote: Is there a decent size icon for Nexus somewhere... suitable for using to setup a SSB via Fluidapp? --jason - 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] - 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, ~t~
Re: Checksum Format for .md5 and .sha1 Files
Not to mention, that there is already a lot of files generated by md5sum and sha1sum apps on central: http://repo2.maven.org/maven2/log4j/log4j/maven-metadata.xml.md5 http://repo2.maven.org/maven2/log4j/log4j/maven-metadata.xml.sha1 But in the above cases, the path is obviously misleading. ~t~ On Fri, Jan 2, 2009 at 5:36 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Brian Fox wrote: I'm -1 to making a new format Just to make sure we all have the same understanding: The proposed format is not new as in yet another checksum format. It's an already existing format used by the md5sum tool (compare the format attribute of Ant's checksum task [0]). Benjamin [0] http://ant.apache.org/manual/CoreTasks/checksum.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Thanks, ~t~
Re: [VOTE] Maven 3.0-alpha-1
+1 :) ~t~ On Mon, Jan 5, 2009 at 1:32 AM, Jason van Zyl jvan...@sonatype.com wrote: Hi, This is really to get the ball rolling for Maven 3.x. While I have some gracious guinea pigs who are arduously pummeling this code base I wouldn't recommend anyone use this in production. If you want to try it and give feedback that's great, but we have a lot of work we know ourselves that needs to be done. Not trying to discourage anyone from trying it but I honestly wouldn't expect much for a at least a couple more weeks. Over the next few alphas the work will be dominated by bug fixing, regression fixing, general alignment with Maven 2.x so that all known requirements to run Maven 2.x plugins are satisfied, and refactoring to prepare the codebase for the fun stuff of adding new features. There is still a lot of work todo, but by the end of January I think I'll have a good enough idea to layout some tentative beta dates and for GA. I know this by guestimating based on myself, Shane, and Oleg working on this full-time and Benjamin working part-time. We are trying extremely hard to make everything accessible by producing tons of ITs, a specification for POM construction and builds coming off the grid at a very high frequency. I hope that fairly soon into the alpha cycle we can attract Ralph into the mix and soon after that more developers. My hope is that by the time the betas rolls around we have 4-5 people who know the core as well as Shane and I do now, and 7-8 by the time we hit GA. I think from this point I would like to try and eject and alpha every week or two with builds coming off the grid many times a day. Please don't expect too much from the distribution if you happen to download it as we know there are problems and we haven't started optimizing at all yet. Shane and I had to do a release before we went batty so we needed to get the process going. I don't think we are going to attempt to integrate newer build of Maven 3.x into m2e for a couple more alphas so anyone doing embedding work I can tell you that it's not time to integrate yet. So without fanfare, here are the standard bits you're looking for: Issues resolved: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=13143pid=10500sorter/field=issuekeysorter/order=DESC Staging repo: http://people.apache.org/builds/maven/3.0-alpha-1/ Distributions: http://people.apache.org/builds/maven/3.0-alpha-1/staging-repo/org/apache/maven/maven-distribution/3.0-alpha-1/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Thanks, ~t~
Re: [vote] use repository.zones.apache.org as the new staging/releasing location for Maven artifacts
Just an idea: don't forget the archetype plugin: https://docs.sonatype.com/display/NX/Nexus+Archetype+Plugin Having it on r.a.o would be awesome. I can easily downgrade is to support Nexus 1.2.x (until 1.3 is not released). ~t~ On Fri, Feb 6, 2009 at 4:52 PM, Brian E. Fox bri...@reply.infinity.nuwrote: I have thought about backing up the repo as well but haven't acted on it for one main reason: the entire content of the apache repository is replicated to central and then around the world to countless sites. There isn't much to lose here that makes me overly concerned about replicating the repo yet again. This is not true of the snapshot repo but losing that is just an inconvenience. That's not to say we can't rsync the storage contents to yet another disk inside of apache if we decide it's needed. -Original Message- From: Jesse McConnell [mailto:jesse.mcconn...@gmail.com] Sent: Friday, February 06, 2009 10:29 AM To: Maven Developers List Subject: Re: [vote] use repository.zones.apache.org as the new staging/releasing location for Maven artifacts well might be a bit belated but I am +1 for this as well, bringing a bit of order to the staging process is a good thing.. my only concern which I have written a number of responses to only to just delete and not send is something that has been brought up a number of times on the infra list... nexus brings a nice level of security to the repo practices that has been missing but I am still a bit concerned on the artifacts on disk from a recovery standpoint...I would feel more comfortable with it if the artifact storage was backed by an scm...maybe not in this particular instance for staging and promotion, but for the actual repo...would be comforting to me. especially if we are starting to move towards having tooling like nexus or archiva sitting over and managing artifacts on a disk. Things like that symbolic link clean issue that was just reported happen and having it backed by a backed up scm would be comforting... my 2 cents, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Feb 6, 2009 at 9:09 AM, Jason van Zyl jvan...@sonatype.com wrote: On 6-Feb-09, at 12:23 AM, Ralph Goers wrote: On Feb 5, 2009, at 10:34 PM, Jason van Zyl wrote: On 5-Feb-09, at 9:53 PM, Ralph Goers wrote: I'm not sure why this needs a vote. Just do it. This requires pulling all of the org.apache.maven.* artifacts into Nexus and that's where they stay for this project because we can't keep partial bits here and over on people. We are suggesting that projects at Apache decide on a per-project basis. So there are currently only two solutions: use people or use Nexus. That's why Brian asked people. I'm confused by your use of people in the last two sentences. The last people could either mean infra or the folks on this list - it obviously isn't p.a.o. I saw all the traffic on Infra where Brian asked about this and was told how. No one objected that I saw when this was mentioned on this list several days ago. I realize you may not want to seem like you are forcing this on anyone, but it seemed to me this was a done deal when infra told Brian to set it up in a zone. But if you want a +1 instead, consider this it. It would be possible to support the staging without moving everything for Maven over into one location, but I would prefer to stick to concrete and currently the best (and only solution) for staging and promotion that isn't painful is Nexus. So we did the staging and thought about how much work it would be to support that and it's far simpler to just move everything for projects that want to use Nexus. I don't want to do a huge amount of work based on the theoretical possibility there will be another option anytime in the near future. Ralph - 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 jason at sonatype dot com -- - 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
Re: [RANT] This Maven thing is killing us....
Hi, just to mention a Maven Proxy alternative Proximity, that collects these kind of stats. Currently (ver RC2) contains a simple Stat implementation that is not transient (on restart it forgets the stats) and it offers only few a top10 views just to demonstrate the feature, the final release will have some more advanced capabilities. Proximity (on the screenshot below) actually shows served artifacts (requested by M2 clients), local hits (items found in local cache) and remote hits (items that had to be [re]fetched from proxied remote reposes)... https://is-micro.myip.hu/~cstamas/proximity-stats.jpg Have fun! ~t~ On 7/3/06, Steve Loughran [EMAIL PROTECTED] wrote: yeah, some httpd stats could be interesting too. Perhaps someone hosting an internal repo could see that. Of course, with caching, you explicitly dont get told whenever something builds against log4j, only when something first pulls it down. There's another reason polling would be interesting I guess; statistics.
Re: [Canceled] [VOTE] Release Maven Archetype plugin version 2.0-alpha-5
We could create a CLI tool out of Nexus Archetype Plugin in similar manner as Nexus Indexer CLI exists (or even make those two CLIs one?) Naturally, the Archetype CLI would required Nexus Indexer CLI (to be able to use Nexus Index to generate the catalog). Of course, if there is some other available tool to be used on central, go for it. This was just an idea :) ~t~ 2009/5/4 Raphaël Piéroni raphaelpier...@gmail.com Due to obviously correct advice, the vote is canceled. I'll try to promote a new build as soon as i can. Brian, how can we have the catalog auto-generated for central on sync or weekly ? Regards, Raphaël 2009/5/4 Brett Porter br...@apache.org Also, I thought having the archetype catalog online was a pre-requisite to this release? - Brett On 04/05/2009, at 4:01 AM, Brian E. Fox wrote: -1 we need to produce source archives for all releases based on the recent discussions on some other lists. I'm experimenting with some ways to make this inherited but for now you can bind the assembly plugin with the src descriptor to produce the correct zip of the sources. --Brian (mobile) On May 3, 2009, at 11:44 AM, Raphaël Piéroni raf...@apache.org wrote: Hi, We solved 11 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14254styleName=HtmlprojectId=11095 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11095status=1 Staging repo: https://repository.apache.org/content/repositories/maven-staging-003/ Staging site (currently syncing): http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
Re: Maven, M2Eclipse, Nexus @ Eclipse DemoCamp in Budapest
Also, two of us will be at University of Szeged on Friday 19th, doing the same we'll be doing some demos and chatting with folks. The beer will came later, most probably at the evening. Anyone around, interested to attend the presentation at University, do some chat and/or beer should contact me directly on my mail, since exact times and pubs are not known yet. Thanks, ~t~ On Sun, Jun 14, 2009 at 9:51 AM, Jason van Zyljvan...@sonatype.com wrote: Hi, Tamás Cservenák and me will be at the Eclipse DemoCamp on Thursday June 18th. If you're interested in M2Eclipse, Maven or Nexus we'll be doing some demos and chatting with folks. Beer will most likely be involved afterward :-) http://wiki.eclipse.org/Eclipse_DemoCamps_Galileo_2009/Budapest Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Stop support for legacy repository layout in 3.x
+1 (non binding) biasedAnd also, some of MRMs are of great use on laptops too, due to their small memory footprints, and they are of great help with decoupling you from work to home schemes ;) /biased ~t~ On Mon, Jul 20, 2009 at 10:07 PM, Jason van Zyl jvan...@sonatype.comwrote: On 20-Jul-09, at 3:12 PM, nicolas de loof wrote: Legacy layout is still used at http://download.java.net/maven/1/ by some project, including some standard Java API (activation, mail, persistence...) can we expect them to migrate to http://download.java.net/maven/2/ ? Maybe some evangelism / lobbying could help ;) I think with a little help we could help them flip it. I know that Kohsuke wants to. I don't think they actually use m1 anymore, they just haven't gotten around to converting it. A repo manager can safely convert such repo on the fly to default layout, but this is an extra infrastructure setup that mostly target entreprises, not considering standalone (laptop) use. For this reason I'm only +0 with this proposal. There are also the conversion tools which don't require any additional infrastructure but a switch. But a repository manager is a best way to migrate I think. As the repository is hidden by Mercury abstraction (AFAIK), would this really make Maven simplier ? Cheers, Nicolas 2009/7/20 Jason van Zyl jvan...@sonatype.com Hi, Maven 2.x has been out for quite some number of years now, and I wanted to float the idea of stopping support for the legacy repository format in 3.x? There are tools now that can convert repository formats, and I believe all of the three popular repository managers support dynamic mapping to legacy format for Maven 1.x clients. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - 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 http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multi-Platform snapshots
I think that extending the repo metadata with full coordinates is still the best general solution. These builds are de facto different builds, I see no value producing them with _same_ timestamp. They will all be resolvable using standard metadata resolution and version 1.0-SNAPSHOT to their latest versions. Since they are different OSes, and different machines, the builds should be considered separate too. Thanks, ~t~ On Mon, Sep 7, 2009 at 3:16 AM, Brian Foxbri...@infinity.nu wrote: I agree, but I got the feeling Brian would like the same version on these parallel builds which will need extra to make sure they are in sync. I'm just exploring the concepts and options. I think most cases could be solved by being able to resolve the latest snapshot of a particular classifier...which means tracking that info in the metadata in addition to what's currently there. I don't know how you would synchronize the output of multiple systems to try and have a consistent version ie timestamp...nor if that would even be better than tracking the classifier. - 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
Re: a cleaned up central repository?
Not to mention that these below are formal requirements only. Their _presence_ is required, but nothing is said about their _content_.I can publish a POM that will _have_ dependencies section, but how do we know that the dependencies section is _correct_? Also: license in POM. What license name is allowed? Are they keyed by by license URL? Etc... Many of these are pretty hard to determine in machine way ~t~ On Tue, Oct 6, 2009 at 2:26 AM, Brian Fox bri...@infinity.nu wrote: On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote: Brian, Ok then, I assert they are all fine. Now you can provide a list and refute me ;-). In this case (if they were all fine) here is your list: http://repo2.maven.org/maven2/.index/ (But unfortunately they are not all fine.) Seriously, the definition of broken depends on the observer. True. This is why maybe there should be different Good lists and users should be allowed to choose, depending on their taste. Before we can fix anything broken we need to start by defining what you think is broken and why. One of the possible Definitions of Good list, which I would like call Maven Central Compliance is defined here: http://maven.apache.org/guides/mini/guide-central-repository-upload.html If artifacts are on Central which are not on this list (which list should really be realized soon), I don't mind, as long as I could search or filter by this list. You cannot objectively define what is broken only if you specify which Lists you are talking about. Do you mean, the Maven Central Compliance list? I assume you mean this list of requirements? There are some requirements for the minimal information in the POMs that are in the central repository. At least these must be present: modelVersion groupId artifactId packaging name version description url licenses scm url dependencies I don't think that I would consider things broken simply because the name, description, url, scm url where missing. I would be annoyed but not surprised if the license wasn't populated correctly. So if you're saying you want to exclude everything from your build simply because one of those are missing, then I think we fundamentally disagree. Yes it would be nice if those were filled in properly but none of those reduce the usefulness of users to a point where they simply should be treated like they don't exist. I consider things broken if the pom doesn't parse, the dependencies are wrong (again subject to perspective in some cases), the gav isn't correct, the checksums or signatures are broken. Otherwise from a repository perspective they are not broken. If you attempt to enumerate all the things in central that match all of those values above and build a repo of only those, it will be a nearly useless repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: a cleaned up central repository?
Sorry, could not stand it: the deprecation data about broken artifacts described in metametadata : metametametadata :D ~t~ On Tue, Oct 6, 2009 at 10:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: metadata is data about data metaanalysis is an analysis of other analyses metaworry is worrying about worrying metacognition is thinking about thinking metametadata is therefore data about metadata the jar is your artifact : data the pom is data about the artifact : metadata the metadata.xml is data about the pom files : metametadata Sent from my [rhymes with tryPod] ;-) On 6 Oct 2009, at 20:02, Albert Kurucz albert.kur...@gmail.com wrote: Steven, http://lmgtfy.com/?q=maven+metametadata Found this 1st: So he's talking about me!? Does that make me a maven? Does mavenhood explain metametametadata? Does it excuse all of its self-referential posts? Are you sick of them yet? Is this clever? Can I ask anymore questions? Um, no. From 2004! On Tue, Oct 6, 2009 at 1:06 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Albert, I think you are confusing the metadata.XML files from the pom.XML files the metadata sonatype are referring to is the metametadata (ie metadata.xml files) and nit the artifact metadata (ie pom.xml files) there are places in central where the metametadata is incorrect. let's get those fixed pom's are more subjective: is log4j 1.2.14 a bad pom? it lists all the dependencies with compile scope and without optional=true in my case, it is a bad pom because on a point release started pulling in windows nt logging support, and my app breaks with that support in place... but it is still a valid pom and it is still a correct pom I could argue that the dependencies could be optional, others could argue that instead the whole log4j should be refactored into multiple artifacts pulling in each of the dependencies I think should be optional... none of us are correct I could argue that a pom which does not list a license is broken... others might say that code in the public domain has no license, so their pom would be incorrect to list a license I could have a closed source artifact on central, so no scm, no developers, no distMgnt, no build, no reporting... and that is still a valid pom the only metadata we can prove to be incorrect is the metametadata... and thankfully that can be reconstructed from the pom files Sent from my [rhymes with tryPod] ;-) On 6 Oct 2009, at 18:30, Albert Kurucz albert.kur...@gmail.com wrote: Brian, This is why in suggestion 1) I said lets get some code to validate the artifacts. Reading this article I thought you already have that http://www.think88.com/resources/Maven_white_paper_june_2009.pdf Sonatype maintains a central repository with more than 90,000 artifacts, consuming more than 60 GB of storage. In addition to the artifacts themselves, the Maven Central Repository also contains a POM-file for each of the artifacts, containing the meta data for these artifacts. To protect the integrity of the repository, Sonatype checks the meta data for correctness. If the meta data is erroneous, the artifact can’t be uploaded. On Tue, Oct 6, 2009 at 12:19 PM, Brian Fox bri...@infinity.nu wrote: On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz albert.kur...@gmail.com wrote: Tamas, I cannot predict when, but once it will be done in a machine way or a mathematical/logical proof will be discovered that it is impossible. Agreed, it will not be easy. This is why in suggestion 1) I said lets get some code to validate the artifacts. Having a suite of validation rules implemented hurts noone and then people can choose to use them or not, it's just like the bunch of enforcer rules we already have. - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: a cleaned up central repository?
Modello? Or any source/code generator? :D ~t~ On Thu, Oct 8, 2009 at 5:05 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: UML is a diagram about software 2009/10/8 Jörg Schaible joerg.schai...@gmx.de Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56: No because metasoftware would be software about software (which makes no sense) Actually it does, it's called UML :)) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Local Repository Optimizations should be removed
Hi there, this is mainly about this issue: http://jira.codehaus.org/browse/MNG-4368 It caused a lot of grief (and lost hours) to me, until I figured what happens on me. IMHO, no optimization like this should be done against local repository. Please undo it. Thanks, ~t~
Re: Local Repository Optimizations should be removed
Well, how about a feature branch (short lived branches)? Or you modify all the modules to have different GAV upon branch? This is kinda nonsense to me, since I branch it to do some feature that I know will get back into trunk. Renaming (changing GAVs of modules, maybe a LOT of them) is PITA in this case, IMHO. But even then, I dislike very much the idea that Maven optimizes this, and does less then I tell it to do ;) ~t~ On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER aherit...@gmail.com wrote: You have the same version in 2 branches in a project ? For me it is a bad practice Each branch has it own version to avoid those sort of conflict. Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net 2009/12/7 Tamás Cservenák ta...@cservenak.net Hi there, this is mainly about this issue: http://jira.codehaus.org/browse/MNG-4368 It caused a lot of grief (and lost hours) to me, until I figured what happens on me. IMHO, no optimization like this should be done against local repository. Please undo it. Thanks, ~t~
Re: Local Repository Optimizations should be removed
Okay, let's put it this way: are you saying that all the different GIT reposes out there containing project A mirrors should have different versions? Who will coordinate those? It's somehow incompatible with Git (and probably any other distributed SCM) in very fundamental way ~t~ On Mon, Dec 7, 2009 at 3:30 PM, Arnaud HERITIER aherit...@gmail.com wrote: ... Renaming (changing GAVs of modules, maybe a LOT of them) is PITA in this case, IMHO. ... mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT And it's done ? Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net 2009/12/7 Tamás Cservenák ta...@cservenak.net Well, how about a feature branch (short lived branches)? Or you modify all the modules to have different GAV upon branch? This is kinda nonsense to me, since I branch it to do some feature that I know will get back into trunk. Renaming (changing GAVs of modules, maybe a LOT of them) is PITA in this case, IMHO. But even then, I dislike very much the idea that Maven optimizes this, and does less then I tell it to do ;) ~t~ On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER aherit...@gmail.com wrote: You have the same version in 2 branches in a project ? For me it is a bad practice Each branch has it own version to avoid those sort of conflict. Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net 2009/12/7 Tamás Cservenák ta...@cservenak.net Hi there, this is mainly about this issue: http://jira.codehaus.org/browse/MNG-4368 It caused a lot of grief (and lost hours) to me, until I figured what happens on me. IMHO, no optimization like this should be done against local repository. Please undo it. Thanks, ~t~
Re: Local Repository Optimizations should be removed
Hi there, Just to refresh memories, there is an interesting debate going on: http://jira.codehaus.org/browse/MNG-4368 BTW, now I do realize that the issue I thought to be my problem, and is used to exchange comments are not the same But the problem is still a problem. Thanks, ~t~ On Mon, Dec 7, 2009 at 4:05 PM, Arnaud HERITIER aherit...@gmail.com wrote: I agree to fix the behavior like you propose Paul. It will reduce probably a little bit current performances but if it solves the case explained by Tamas, why not ... On Mon, Dec 7, 2009 at 4:01 PM, Paul Gier pg...@redhat.com wrote: It seems that the copyFileIfModified implementation should be changed. Since currently it only checks if the source timestamp is newer. Maybe this should be changed to check for the timestamps not equal (and maybe size not equal also) instead of just a newer timestamp. That would allow the optimization, but also handle the use case described in the jira issue. Tamás Cservenák wrote: Well, how about a feature branch (short lived branches)? Or you modify all the modules to have different GAV upon branch? This is kinda nonsense to me, since I branch it to do some feature that I know will get back into trunk. Renaming (changing GAVs of modules, maybe a LOT of them) is PITA in this case, IMHO. But even then, I dislike very much the idea that Maven optimizes this, and does less then I tell it to do ;) ~t~ On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER aherit...@gmail.com wrote: You have the same version in 2 branches in a project ? For me it is a bad practice Each branch has it own version to avoid those sort of conflict. Arnaud Héritier Software Factory Manager eXo platform - http://www.exoplatform.com --- http://www.aheritier.net 2009/12/7 Tamás Cservenák ta...@cservenak.net Hi there, this is mainly about this issue: http://jira.codehaus.org/browse/MNG-4368 It caused a lot of grief (and lost hours) to me, until I figured what happens on me. IMHO, no optimization like this should be done against local repository. Please undo it. Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Shade Plugin 1.3.1
+1 Thanks, ~t~ On Thu, Jan 21, 2010 at 7:28 AM, Hervé BOUTEMY herve.bout...@free.frwrote: +1 Hervé Le lundi 18 janvier 2010, Benjamin Bentmann a écrit : Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540version=16 111 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11540st atus=1 Staging repo: https://repository.apache.org/content/repositories/maven-048/ Staging site (sync pending): http://maven.apache.org/plugins/maven-shade-plugin-1.3.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - 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
Re: [VOTE] Release Maven Resources Plugin 2.4.2 and Maven Filtering 1.0-beta-4
+1 Thanks, ~t~ On Thu, Feb 18, 2010 at 1:46 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11145version=15604 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=14861 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11145status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761status=1 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Staging sites (sync pending): http://maven.apache.org/plugins/maven-resources-plugin-2.4.2/ http://maven.apache.org/shared/maven-filtering-1.0-beta-4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re : [VOTE] Release Apache Maven 3.0-alpha-7
+1 On Wed, Mar 10, 2010 at 10:18 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven EJB Plugin 2.2.1
+1 On Wed, Mar 17, 2010 at 10:28 PM, Olivier Lamy ol...@apache.org wrote: +1 2010/3/17 Benjamin Bentmann benjamin.bentm...@udo.edu: Hi, We solved 2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11134version=16294 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11134status=1 Staging repo: https://repository.apache.org/content/repositories/maven-001/ Staging site (sync pending): http://maven.apache.org/plugins/maven-ejb-plugin-2.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://fr.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0-beta-1
+1 On Mon, Apr 19, 2010 at 7:50 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, We solved 39 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16089 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-042/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.0-beta-1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-archetype-plugin 2.0-beta-5 and Central
Just a question: will use central catalog, or the catalog got from the _roor_ of defined reposes? In other word: will mirrorOf affect from where is catalog pulled? Asking, since initially when I talked to Raphael wrt nexus-archetype-plugin, the main reason why this plugin put the catalog in the root of reposes was exactly this: transparently publish archetypes to users Juven: good work! We have now all archetypes present in central enlisted! Thanks, ~t~ On Sun, Mar 28, 2010 at 12:18 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Hi, I'm working on Maven Archetype Plugin, helped by Raphael who explained me lots of things (thank you Raphael). maven-archetype-plugin 2.0-beta-5 will use Central catalog as default instead of internal. But this catalog is actually empty [1]. Question: how to update it? Run crawl Mojo against Central once a day, for example? Regards, Hervé [1] http://repo1.maven.org/maven2/archetype-catalog.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release some Maven Archetypes
+1 On Apr 30, 2010, at 5:12 PM, Hervé BOUTEMY wrote: ping :) I added a usage note on every archetype site to quickly test creating a project from an archetype, if it can help... Hervé Le mardi 27 avril 2010, Hervé BOUTEMY a écrit : Hi, I want to release Maven Archetypes parent pom - maven-archetype-bundles version 4- and some Maven Archetypes: - maven-archetype-plugin version 1.1 - maven-archetype-plugin-site version 1.1 - maven-archetype-quickstart version 1.1 - maven-archetype-site version 1.1 - maven-archetype-site-simple version 1.1 Staging repo: https://repository.apache.org/content/repositories/maven-028/ Site: http://maven.apache.org/archetype/maven-archetype-bundles/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Here is my +1 Hervé - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Julia Antonova/Tumlare is out of office.
Update the wiki/FAQ please! Thanks, ~t~ On Sat, Jun 12, 2010 at 8:18 PM, Wayne Fay wayne...@gmail.com wrote: Wahoo Julia going on break is like the summer solstice. ;-) wf On Sat, Jun 12, 2010 at 9:36 AM, Paul Benedict pbened...@apache.org wrote: If anyone should be allowed to send an OOO reminder, it's definitely Julia. Let the ceremonial rituals begin! I believe she has marked the start of the summer vacation season for us. Paul On Sat, Jun 12, 2010 at 7:04 AM, sebb seb...@gmail.com wrote: Have you seen this? http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-IsJuliaAntonova/Tumlareoutoftheoffice ? But I agree it's annoying. The problem is that there are lots of different ways of denoting OoO messages. Just matching on subject line will result in false positives. I think many of them have the header: Auto-Submitted: auto-generated which is unlikely to be present in proper postings. On 12/06/2010, Martin Gainty mgai...@hotmail.com wrote: these transmissions are annoying and rude..is there a way we can filter emails from corporate is off the list maybe a maven-filter-plugin activated by quartz scheduler that reads out of office and redirects to the round-file? bedankt, Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Subject: Julia Antonova/Tumlare is out of office. From: juli...@tumlare.com To: dev@maven.apache.org Date: Sat, 12 Jun 2010 15:32:55 +0400 I will be out of the office starting 12.06.2010 and will not return until 15.06.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MDEP-269] please review
I don't get it, what do you mean by repository index generated by Nexus ... doesn't include the artifact hash? What makes you think hash is not on the index? Thanks, ~t~ On Fri, Jun 18, 2010 at 11:52 AM, nicolas de loof nicolas.del...@gmail.comwrote: Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies I've attached a patch to Jira as I'd like your opinion on the way to support this use case. My patch uses Nexus REST API to query the repository manager for artifacts based on local files SHA1 hash. The query URL is configurable, and the Xpath expression to extract data should also, so that a non-nexus repository manager that provides comparable feature may be user. Maybe there is more performant/portable way to do this, for example using repository index generated by Nexus (not sure if other repository manager do the same) but this one doesn't include the artifacts hash yet (NEXUS-3596 http://issues.sonatype.org/browse/NEXUS-3596) WDYT ? Nicolas
Re: [MDEP-269] please review
Well, we had an issue: https://issues.sonatype.org/browse/NEXUS-644 but it was fixed more then a year ago... maybe he suffered from that one? But index downloaded from central was never suffering from this issue (it is not a Nexus instance, and Central would not be a group anyway). Use the latest release of Nexus Indexer and please test it. If you find hashes usable, please close the issue. Note: In issue above MD5 hashes are mentioned, but MD5 is not supported anymore, not on index. Only SHA1 hashes are. Thanks, ~t~ On Fri, Jun 18, 2010 at 10:35 PM, nicolas de loof nicolas.del...@gmail.comwrote: I discussed with the author of alf-maven-osecm (that suggested me this feature) and he reported me he first tried to use the repo index but didn't find the hash in it. I've not tried by myslef. If hash is included, please close my Jira issue on Nexus and I'll double check this. 2010/6/18 Tamás Cservenák ta...@cservenak.net I don't get it, what do you mean by repository index generated by Nexus ... doesn't include the artifact hash? What makes you think hash is not on the index? Thanks, ~t~ On Fri, Jun 18, 2010 at 11:52 AM, nicolas de loof nicolas.del...@gmail.comwrote: Hi folks, I'm working on MDEP-269 http://jira.codehaus.org/browse/MDEP-269 - convert a legacy lib/*.jar to maven dependencies I've attached a patch to Jira as I'd like your opinion on the way to support this use case. My patch uses Nexus REST API to query the repository manager for artifacts based on local files SHA1 hash. The query URL is configurable, and the Xpath expression to extract data should also, so that a non-nexus repository manager that provides comparable feature may be user. Maybe there is more performant/portable way to do this, for example using repository index generated by Nexus (not sure if other repository manager do the same) but this one doesn't include the artifacts hash yet (NEXUS-3596 http://issues.sonatype.org/browse/NEXUS-3596) WDYT ? Nicolas
Re: Julia Antonova/Tumlare is out of office.
OMG Do we have a mole within Maven project? :D :D Thanks, ~t~ On Wed, Jun 30, 2010 at 12:44 PM, Julia Antonova juli...@tumlare.comwrote: I will be out of the office starting 30.06.2010 and will not return until 01.07.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com Thank you!
Re: Merging in our Aether and Guice changes to Maven 3.x
Hi there, As for Guice, I think that what JVZ said does stands: a very few people does understand how big and complex that work was (and is, since it is ongoing). Stuart did a real magic, with just a drop in replacement for Plexus-components backed by Guice. But don't stop there. With his foundation, it is very easy and straight-forward to create any IoC lingo, just as Plexus shim is implemented. What I really loved about it, is the fact, that reimplementing Nexus Plugin API (and it's internals) using spice-inject boiled down to few very simple modules. Before, it was a pile of asm+deep-plexus-trickery+classworlds heavy lifting and complex, error prone code. Now it is a beautiful and simple. The previous was written by me, but I felt no sorry for ditching it, not a teardrop at all. A big +1 for it. As for Aether, only few comments from Apache newbie. I did lurk a lot of time around Apache project, especially Maven. Was present on lists, was following the project even if I was not a committer, had no merits (neither have now) and was not a member for a long time (today I am). But due to my private OSS project, I present with my Proximity Maven Proxy implementation a little bit, and was participating mostly on these lists. So, I am kinda aware of The Apache Way, did seen it in action. IMO, the decision here is more about The Apache Way and something else. I think everyone spent some time on Github, and I am always amazed how quickly things get picked up, changed, modded and thrown back at you there, The speed (in it's broadest sense) over there is awesome, like there is no mass, hence no inertia force is applicable there. Here, you have a limited (small) set of people with committer rights, with direct or indirect infra access, and even if someone is at full throttle, the project itself is doomed with this bottleneck, people cannot gain momentum unless they are in this circle. We saw a lot of insiders saying they can't do it now, they have other (like for example work related) obligations, family, etc. There, you have literally open set (kinda unlimited) of potential collaborators, and the work does not stop. In any moment, everybody being active are actually at the top of their momentum. But if someone does retire for a week or month, still leaves his work free and at disposal to others. But I have to agree with Brett, centralized issue tracking is a bliss. Over here, I see a lot of bureaucracy, different dams that just makes things swim slower. And this is not the git vs svn story at all, this is more about flow. Code and idea flow. The juice. Just like Stephen Connolly told, here you hit walls and usually loose the momentum. When your JIRA with patch get's absorbed, you will usually have the wtf? moment at first when the JIRA mail lands in your mailbox. But there are lot of nice pros over here too not to be lost: things like backing organization, tied community, togetherness and all those other nice things Apache is known for. Maybe we need to merry these two? This Apache Way was maybe superior back then when it all started. But today, as everything is speeding up, I kinda feel this way just makes people... well, loose the momentum. And this applies to projects too. Aether is ASLv2, I see no problem here taking it under Apache umbrella if it's backing company shuts down. Aether as external project is really something as Plexus was (still is but I see positive opinionated people regarding ditching it). It was/is essential part of Maven, but even then it was external. I personally think, that trowing Aether into some whirling creek (like github, codehaus or even eclipse) is a very good option. Not just it will be more easily adopted by 3rd parties, but also it will be a general commissar for Maven out there in the wild. This is a problem of merits too. I do understand people dislike the idea to ditch some code with they were involved with for a long time, and was probably increasing/representing their merits. We all were there at least once. But I cannot agree more with JVZ, that merits should melt and vaporize, should be considered somewhat temporal. The single amount of work made today should count more than single amount of work made a year ago and so on. At least wrt decisions made today. When it's about beer and fun, naturally the one having most absolute merits (without the time factor that makes it melt) should pay the beer and margaritas, beyond question, and we, without merits, should just enjoy the beer in great companionship ;) Any Maven emeritus anywhere around central Europe in near future? :D In general, and aside all this philosophy above, I agree very much with Arnaud. I think he nailed it. Thanks, ~t~ Disclaimer: I am involved with Sonatype. This mail does not represent any internally approved or Sonatype opinion, it is strictly my private opinion.
Re: guice memory usage was: (3.0 beta 2/3/4 roadmap was Re: Merging in our Aether and Guice changes to Maven 3.x)
Cool! +1 for merges! Thanks, ~t~ 2010/8/18 Arnaud Héritier aherit...@gmail.com Hi, I just rebuilt aether and maven3 and I have now : 14M/125M We are really near of 9M/125M we have in beta2 Perfect !!! Let's go for a merge in trunk ?? Arnaud
Re: Is packagingmaven-archetype/ required/recommended for archetypes?
Howdy, As for [2], the nexus-indexer tries it's best to recognize (or guess is maybe better) is an artifact an archetype or not, exactly because of that mixup with packaging, etc. Considering all archetypes out there in central, there is no unique way to decide... when an artifact is recognized as archetype (or even partial archetype), the indexer _overrides_ the packaging on index and makes it uniformly maven-archetype packaging (yes, even for those that has POMs saying different). And finally, the nexus-archetype CLI (used on central to generate the catalog, but same stands for Nexus Archetype Plugin, that uses same components) will simply put only those artifacts into catalog, that on index have packaging (are recognized as) maven-archetype. Actually, this index creator is meant to override the packaging to maven-archetype if needed, hence, to recognize older archetypes, since newer ones already presents themselves with correct packaging, and packaging is handled in generic fashion by MinimalArtifactInfoIndexCreator: Following steps are done to recognize archetypes (below). - if packaging is maven-archetype, or extension is not jar, no action needed (the minimal index creator already sets packaging) - if extension is jar, and the JAR contains some of these resources: /META-INF/maven/archetype.xml, /META-INF/archetype.xml, /META-INF/maven/archetype-metadata.xml, override it's packaging to maven-archetype Source code is here: https://sventon.sonatype.org/repos/nexus-oss/show/trunk/nexus-indexer/src/main/java/org/sonatype/nexus/index/creator/MavenArchetypeArtifactInfoIndexCreator.java?revision=HEAD Hope this helps to resolve problems about version 1.1 of webapp-javaee6 === And as Herve said, it is best to use proper archetype packaging for any new archetype. Thanks, ~t~ On Tue, Sep 28, 2010 at 4:34 PM, Jesse Glick jesse.gl...@oracle.com wrote: [2] Another curious thing: though the mojo-archetypes appear to have always used jar packaging, and e.g. webapp-javaee6 in Central lists the packaging as jar when you download the POM for 1.0, 1.0.1, 1.0.2, and 1.1, the Central index lists the packaging as maven-archetype for 1.0, 1.0.1, and 1.0.2 - but not 1.1. Why? Furthermore, http://repo1.maven.org/maven2/archetype-catalog.xml lists 1.0, 1.0.1, and 1.0.2, but not 1.1. Nor, now, 1.2 - as someone was just complaining on us...@mojo, webapp-javaee6 1.2 is not offered by m2eclipse.
Re: [VOTE] Release Apache Maven 3.0
+1 Woohoo! Thanks, ~t~ On Mon, Oct 4, 2010 at 2:16 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, feedback on the RCs seems to be decreasing and I am currently not aware of any major regression so let's try and cross the finishing line of this marathon. We solved 31 issues since 3.0-beta-3: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=13142 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Patch for ARCHETYPE-303
Hi there, I attached the patch for solving http://jira.codehaus.org/browse/ARCHETYPE-303 Externalize Archetype Catalog model into separate module issue. This patch externalizes (moves out into separate module) each modello model, leaving just the old 1.x archetype.mdo in archetype-commons. Could please someone (Herve?) review it and apply? Thanks, ~t~
Re: Patch for ARCHETYPE-303
Hi, glad you like it :) Just to clear up: the initial reason for this was to make integration of archetype-based solutions easier into non-maven apps. For example, for nexus-archetype-plugin, I really needed the model _only_, nothing else, so I stole the modello mdo file of archetype-catalog (and create ARCHETYPE-303 issue along) and put that into nexus plugin (it was simpler than dragging in archetype-common and have zillion of excludes just to reach the model and nothing else). On the other hand, Maven Indexer (former Nexus Indexer) was offering -- mostly for IDE integrations -- an indexer based ArchetypeDataSource, so maven indexer needs that interface only, but not the catalog model. Finally, we ended up with doubled models in Nexus -- they are completely separated by plugin-classloaders, etc and not causing any problem at all -- but still, I wanted a cleanup since it was not correct (and tattletale was pushing me to do it :D ). After this change, the nexus-archetype-plugin will just reference the archetype-catalog model as external dependency, just as it needed to be in first place. And at the end, like in good bedtime stories, after this change: http://svn.apache.org/viewvc?view=revisionrevision=1036665 it all proved non-issue: Indexer based ArchetypeDataSource is not widely used -- as far as I know, in IDEs only -- and is not used in Nexus at all :D But still, having separate models will still ease of some next potential integrator's life. Thanks, ~t~ On Thu, Nov 18, 2010 at 11:58 PM, Brett Porter br...@apache.org wrote: Sounds like a good enhancement. You can actually commit it yourself if you'd like (and then perhaps for specific review if you are unsure) - lazy consensus and relying on version control are fine :) Additionally it's actually easier to review this commit in SVN in this case since you're moving files around the patch has a lot of + / - noise. Thanks, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1036834 - in /maven/archetype/trunk: ./ archetype-common/ archetype-common/src/main/mdo/ archetype-models/ archetype-models/archetype-catalog/ archetype-models/archetype-catalog/src/
What? What eol style? Is there any other proper OS on planet Earth aside UNIX? :D Sorry, you were true. SVN client is now properly configures, by the book. What should happen with committed files? How to reapply properties there? Thanks, ~t~ On Fri, Nov 19, 2010 at 2:45 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi Tamás, The new files are missing SVN properties, especially svn:eol-style, please check your SVN client is properly configured [0]. Benjamin [0] http://maven.apache.org/developers/committer-environment.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1036834 - in /maven/archetype/trunk: ./ archetype-common/ archetype-common/src/main/mdo/ archetype-models/ archetype-models/archetype-catalog/ archetype-models/archetype-catalog/src/
Hi Hervé, actually, everything (Maven CLI console output AND the surefire output) is in commit log: http://svn.apache.org/viewvc?view=revisionrevision=1036834 If helps: MacOSX, 1.6.5, java 1.6.0_22 (the boxed one), Maven trunk, locally built (Apache Maven 3.0.1-SNAPSHOT (r1035629; 2010-11-16 14:20:12+0100)) Ping me if anything else needed! Thanks, ~t~ On Sun, Nov 21, 2010 at 6:24 PM, Hervé BOUTEMY herve.bout...@free.frwrote: uh, you have this test in error? I don't have any problem on my computer, nor Hudson on grid I didn't work on these unit tests before, since everything was ok: seems it's time to investigate Can you send me the Surefire output of this failing test? Hervé Le vendredi 19 novembre 2010, csta...@apache.org a écrit : Author: cstamas Date: Fri Nov 19 13:37:58 2010 New Revision: 1036834 URL: http://svn.apache.org/viewvc?rev=1036834view=rev Log: ARCHETYPE-303: applied fix, externalizing all the models into separate project (except the deprecated one, that is left where it was). Note: Before applying this change, there was test failures in archetype-common module (see below). But since this change is actually just moving/shuffling models around (no code change involved), it simply retained this fact, hence that same test still fails. Tests in error: testArchetyper(org.apache.maven.archetype.test.ArchetyperRoundtripWithProx yTest) --- Test set: org.apache.maven.archetype.test.ArchetyperRoundtripWithProxyTest -- - Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 91.745 sec FAILURE! testArchetyper(org.apache.maven.archetype.test.ArchetyperRoundtripWithProx yTest) Time elapsed: 91.738 sec ERROR! org.apache.maven.archetype.exception.UnknownArchetype: The desired archetype does not exist (org.apache.maven.test:test-project-2:1.0) at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.getArchetyp eFile(DefaultArchetypeGenerator.java:88) at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArc hetype(DefaultArchetypeGenerator.java:207) at org.apache.maven.archetype.DefaultArchetypeManager.generateProjectFromArch etype(DefaultArchetypeManager.java:71) at org.apache.maven.archetype.test.ArchetyperRoundtripWithProxyTest.testArche typer(ArchetyperRoundtripWithProxyTest.java:193) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Patch for ARCHETYPE-303
Sure, will try to keep up. I had a year ago (while doing nexus-archetype-plugin) a discussion with Raphael Pieroni (sorry for ASCII-zation of his name!), is he The Man to ping? Thanks, ~t~ On Sun, Nov 21, 2010 at 6:01 PM, Hervé BOUTEMY herve.bout...@free.frwrote: Le jeudi 18 novembre 2010, Brett Porter a écrit : Could please someone (Herve?) review it and apply? You can actually commit it yourself if you'd like (and then perhaps for specific review if you are unsure) - lazy consensus and relying on version control are fine :) +1, even if I'm a little late archetype is not *my* component: it's good to have other people working on it don't hesitate to continue :) Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.0.1
+1 On Tue, Nov 23, 2010 at 12:23 PM, chemit che...@codelutin.com wrote: On Tue, 23 Nov 2010 12:18:15 +0100 Benjamin Bentmann benjamin.bentm...@udo.edu wrote: +1 (non binding) thanks. Hi, 3.0.1-RC1 seems to be fine, thanks to those who tested it. So let's do the real thing. We solved 21 issues since 3.0: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=16331 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-004/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-004/org/apache/maven/apache-maven/3.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Simple Standalone Maven Indexer Example
Hi, here is a basic example, covering -- I hope -- all you need: https://github.com/cstamas/maven-indexer-examples/tree/master/indexer-example-01 Thanks, ~t~ On Tue, Dec 14, 2010 at 9:25 PM, Ersin ER ersin...@gmail.com wrote: Hello, I am trying to implement a simple standalone maven indexer tool without any success. I have included the following dependency in my pom.xml: dependency groupIdorg.apache.maven.indexer/groupId artifactIdindexer-core/artifactId version3.1.0/version /dependency Then I tried to do something similar to the explanations here: https://docs.sonatype.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample That page seems to be outdated and I could not figure out how to map that usage to current version of the indexer. I also included maven-embedded 3.x as dependency (should I) but it seems it also changed. The main problem is that I cannot instantiate plexus (should I) so remaining things also do not work. I am want to point to maven central repository (basically its index) and create a local index to search over. Could you please help with a basic example? Thanks! -- Ersin Er
Re: Moving scm to java 1.5
+1 On Tue, Dec 28, 2010 at 10:19 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: +1 S. On Tue, Dec 28, 2010 at 9:15 PM, Olivier Lamy ol...@apache.org wrote: Hi, As we will start a new year, I'd like to move scm to java 1.5. Let me know if you have any trouble regarding this . (jira entry http://jira.codehaus.org/browse/SCM-591) Thanks, -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.0.0
Hi Brett, originally the targeted version was 3.5, but I was talked out from it. This is Open Source, and version does not hold any marketing value, and 3.5 would be a marketing version (especially when there is no previous 3.4.0 to back it). In short, it's the Maven3 model (vs Maven2.x model) + Aether (vs maven-artifact 2.x) + Lucene 3.0.3 (vs Lucene 2.4.1) and MINDEXER-2 that introduced some important API change. For historical reasons (unfortunately), Indexer API contains Lucene classes, hence library consumer is simply _forced_ to upgrade. This might cause trouble if Lucene is used in other places too in same app. If you consider plain java apps (neglect OSGi and related stuff), this change forces the consuming app to change a _lot_ on it's classpath. While hiding the Maven3 models and Aether is possible (they are not exposed directly), hiding Lucene is not quite so easy (see above) even with modules-enabled containers. For legacy consumers, not being able to move to maven3 or lucene 3, there is the prepared to be 3.2.0 branch, that contains important bugfixes, but not these changes/upgrades from above (it's still maven model 2.x + maven-artifact 2.x + lucene 2.4.1). We can release 3.2.0 too, if there is need for it. Again, I am fine with any version larger than 3.2.0 like 3.5 is (3.1.0 is 1st ASF release of Indexer, branch is set for 3.2.0), but again, personally I don't imply any meaning to version except they order the releases on time axis and in artifact space :) Personally, I even believe they don't have to be strictly increasing (without gaps). If a staged (not released yet, just staged!) release found to be bad, just flush it, and do another v+1 one. Thanks, ~t~ On Tue, Jan 11, 2011 at 10:35 PM, Brett Porter br...@apache.org wrote: Just curious, what is the motivation for the large version bump? - Brett On 12/01/2011, at 7:35 AM, Brian Demers wrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17017 ** Improvement * [MINDEXER-4] - Upgrade to Lucene 3.0.3 * [MINDEXER-7] - Make IndexingContext be able to receive remote updates and index local content simultaneously ** New Feature * [MINDEXER-1] - Introduce MergedIndexingContext, an IndexingContext implementation that gives RO view on multiple IndexingContexts presented logically as one * [MINDEXER-2] - Make Indexer threadsafe ** Task * [MINDEXER-5] - Upgrade to Maven 3.0 models * [MINDEXER-6] - Use Aether version implementation Staging repo: https://repository.apache.org/content/repositories/maven-016/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 NOTE: add binding or non-binding -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.0.0
+1 On Tue, Jan 11, 2011 at 9:35 PM, Brian Demers brian.dem...@gmail.comwrote: Hi, We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17017 ** Improvement * [MINDEXER-4] - Upgrade to Lucene 3.0.3 * [MINDEXER-7] - Make IndexingContext be able to receive remote updates and index local content simultaneously ** New Feature * [MINDEXER-1] - Introduce MergedIndexingContext, an IndexingContext implementation that gives RO view on multiple IndexingContexts presented logically as one * [MINDEXER-2] - Make Indexer threadsafe ** Task * [MINDEXER-5] - Upgrade to Maven 3.0 models * [MINDEXER-6] - Use Aether version implementation Staging repo: https://repository.apache.org/content/repositories/maven-016/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 NOTE: add binding or non-binding
Re: [ANN] Maven Indexer version 4.0.0 Released
Hi, until then (site + doc'd), here is a showcase created for a user asking for examples on this same mailinglist (somewhere in december, but he was interested in using it with plexus too): https://github.com/cstamas/maven-indexer-examples I plan to add more examples here, so if anyone has an idea, shoot! Initially, I did this as a quick response to user's mail, but we could move this code into ASF SVN next to indexer sources Thanks, ~t~ On Wed, Jan 19, 2011 at 4:24 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hello, The site is on the todo list. Other then the default reports. Is there anything specific anyone wants to see? CLI help page basic api example for crawling The above would be a good starting point to get at least an impression how to use this and what is able to do... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.7.2
+1 Thanks, ~t~ On Jan 22, 2011 8:55 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Hi, We solved 31 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17030 Most noteworthy is http://jira.codehaus.org/browse/SUREFIRE-257 being solved, which is the third most upvoted of all maven issues ever. Even though this is just a .1 release it is no small release, so your testing is appreciated. There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-066/ Staging site: http://maven.apache.org/plugins/maven-surefire-plugin-2.7.2/ http://maven.apache.org/plugins/maven-failsafe-plugin-2.7.2/ http://maven.apache.org/plugins/maven-surefire-report-plugin-2.7.2/ http://maven.apache.org/surefire/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven ear Plugin version 2.5
+1 On Wed, Jan 26, 2011 at 11:44 AM, Lukas Theussl ltheu...@apache.org wrote: +1 -Lukas Stephane Nicoll wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132version=16706 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11132status=1 Staging repo: https://repository.apache.org/content/repositories/maven-076/ Staging site: http://maven.apache.org/plugins/maven-ear-plugin-2.5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 My +1 S. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: '+1' vs 'I agree'
Arnaud, what do you agree with? :) Thanks, ~t~ 2011/1/26 Arnaud Héritier arnaud.herit...@exoplatform.com: I agree :-) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: '+1' vs 'I agree'
I Agree :) 2011/1/26 Arnaud Héritier arnaud.herit...@exoplatform.com: I agree to say I agree when I agree with something instead of using +1 :-) Do you agree ? Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Where to list all @threadSafe plugins and components?
Just to chime in: Maven Indexer already cranks up and parses plugin.xml to gather the plugin prefix and existing goals Thanks, ~t~ On Tue, Feb 8, 2011 at 11:00 PM, Jason van Zyl ja...@sonatype.com wrote: On Feb 8, 2011, at 4:54 PM, Dennis Lundberg wrote: My current focus is on the Apache Maven project's plugins and components. I think it is up to all plugin authors out there to document their own plugins. Same plugin could be run on the Apache Nexus instance. They have to mark the mojos as theadsafe, but you could easily generate the list so people would know, or could even be metadata IDEs could consume to guide users if they are to find @threadsafe plugins. On 2011-02-08 22:36, Jason van Zyl wrote: Write a Nexus plugin that walks a repository looking for Maven plugins, crack it open and pull out the metadata and make a report. You could take the Nexus Archetype plugin as an example. If you wanted to create a global list this is the only real way you could accomplish this. On Feb 8, 2011, at 3:41 PM, Dennis Lundberg wrote: I think it would be a useful service to our users to list which plugins and components are @threadSafe, and also in which version it was first marked as @threadSafe. We can start writing things down on the wiki page you mentioned. I'll add a new heading and start to accumulate the info. We can move it to the Maven site when we are done. Perhaps each plugin should have that info on its own site? On 2011-02-07 21:39, Kristian Rosenvold wrote: find . -name *Mojo.java | xargs grep threadSafe I suppose that may not be good enough ;) I was hoping to get all the non-deprecated core plugins @threadSafe, and by the looks of it it's not that far off. If I subtract the retirement-candidates there only seem to be a few left. I'm not technically sure it helps, but I'd generally expect users running parallel to be running the latest versions of everything. I don't think it'd be *that* much work to make a wiki page or similar describing when each plugin/lib was declared threadsafe, since it's all in jira. Would we still need it if I just ran through the remaining plugins ? As you're aware I've documented known problematic libraries at [1], but I'm open to doing something else/more. Kristian ma., 07.02.2011 kl. 18.57 +0100, skrev Dennis Lundberg: Hi I'd like to start a list of which versions of plugins and components are @threadSafe. Where should we have such a list? [1] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 - We all have problems. How we deal with them is a measure of our worth. -- Unknown -- Dennis Lundberg - 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
Re: Where to list all @threadSafe plugins and components?
http://jira.codehaus.org/browse/MINDEXER-11 Please comment. Thanks, ~t~ 2011/2/9 Tamás Cservenák ta...@cservenak.net: Just to chime in: Maven Indexer already cranks up and parses plugin.xml to gather the plugin prefix and existing goals Thanks, ~t~ On Tue, Feb 8, 2011 at 11:00 PM, Jason van Zyl ja...@sonatype.com wrote: On Feb 8, 2011, at 4:54 PM, Dennis Lundberg wrote: My current focus is on the Apache Maven project's plugins and components. I think it is up to all plugin authors out there to document their own plugins. Same plugin could be run on the Apache Nexus instance. They have to mark the mojos as theadsafe, but you could easily generate the list so people would know, or could even be metadata IDEs could consume to guide users if they are to find @threadsafe plugins. On 2011-02-08 22:36, Jason van Zyl wrote: Write a Nexus plugin that walks a repository looking for Maven plugins, crack it open and pull out the metadata and make a report. You could take the Nexus Archetype plugin as an example. If you wanted to create a global list this is the only real way you could accomplish this. On Feb 8, 2011, at 3:41 PM, Dennis Lundberg wrote: I think it would be a useful service to our users to list which plugins and components are @threadSafe, and also in which version it was first marked as @threadSafe. We can start writing things down on the wiki page you mentioned. I'll add a new heading and start to accumulate the info. We can move it to the Maven site when we are done. Perhaps each plugin should have that info on its own site? On 2011-02-07 21:39, Kristian Rosenvold wrote: find . -name *Mojo.java | xargs grep threadSafe I suppose that may not be good enough ;) I was hoping to get all the non-deprecated core plugins @threadSafe, and by the looks of it it's not that far off. If I subtract the retirement-candidates there only seem to be a few left. I'm not technically sure it helps, but I'd generally expect users running parallel to be running the latest versions of everything. I don't think it'd be *that* much work to make a wiki page or similar describing when each plugin/lib was declared threadsafe, since it's all in jira. Would we still need it if I just ran through the remaining plugins ? As you're aware I've documented known problematic libraries at [1], but I'm open to doing something else/more. Kristian ma., 07.02.2011 kl. 18.57 +0100, skrev Dennis Lundberg: Hi I'd like to start a list of which versions of plugins and components are @threadSafe. Where should we have such a list? [1] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 - We all have problems. How we deal with them is a measure of our worth. -- Unknown -- Dennis Lundberg - 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
Re: Julia Antonova/Tumlare is out of office.
Wiki updated. On Tue, Feb 22, 2011 at 8:07 PM, Julia Antonova juli...@tumlare.com wrote: I will be out of the office starting 22.02.2011 and will not return until 24.02.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resources Plugin version 2.5
+1 Thanks, ~t~ On Thu, Feb 24, 2011 at 11:22 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Dennis Lundberg wrote: Staging repo: https://repository.apache.org/content/repositories/maven-047/ Staging site: http://maven.apache.org/plugins/maven-resources-plugin-2.5/ +1 Benjamin - 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
Re: [VOTE] Release Maven Remote Resources Plugin version 1.2
+1 Thanks, ~t~ On Thu, Feb 24, 2011 at 8:44 PM, Dennis Lundberg denn...@apache.org wrote: Hi, We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391styleName=Htmlversion=15620 Note that MRRESOURCES-51 Publish the XML schemas for remote-resources and supplemental-model will be resolved when the release vote has passed. There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11391status=1 Staging repo: https://repository.apache.org/content/repositories/maven-046/ Staging site: http://maven.apache.org/plugins/maven-remote-resources-plugin-1.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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
Re: [VOTE] Release Apache Maven 3.0.3
+1 On Feb 28, 2011 6:59 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, Thanks to those who tested the RC, I think we can move on to the real thing now. We solved 29 issues since 3.0.2: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=17061 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10500status=1 Staging repo: https://repository.apache.org/content/repositories/maven-065/ Staged source and binary distros: https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.0.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire Plugin version 2.8
+1 On Mar 9, 2011 10:41 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Hi, We solved 16 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17039 The ability to run a single test method is the new feature in this release: http://jira.codehaus.org/browse/SUREFIRE-577 A significant memory leak fix for those with really long reactor builds: http://jira.codehaus.org/browse/SUREFIRE-711 Also noteworthy is http://jira.codehaus.org/browse/SUREFIRE-700, which has been hampering evolution of surefire itself severely for years. There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-009/ Staging site: (Sync pending) http://maven.apache.org/plugins/maven-surefire-plugin-2.8/ http://maven.apache.org/plugins/maven-failsafe-plugin-2.8/ http://maven.apache.org/plugins/maven-surefire-report-plugin-2.8/ http://maven.apache.org/surefire/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 And here's my +1 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1086889 - /maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/packer/NEXUS4149TransferFormatTest.java
Hi, completely agreed, but let me explain -- not that it matters: I had a lot of accumulated changes in my github fork of maven-indexer, and initially did not wanted to disturb other forks of my repository. Hence, I started pushing changes _without_ changing commit messages first -- thinking it would change history, hence screw other forks. I was distracted with ASF SVN mirroring pain (dcommiting multiple commits from EU, --no-rebase was not helping, there was a lot of interlaving changes for same file), but solved luckily: http://twitter.com/#!/cstamas/status/53021178750701568 And then I realized: git-svn _also modifies_ history, but it was late then :( I already started pushing (and had to recover few times until I found out the dnsmasq fix), since there was a LOT of commits to be dcommited back to ASF SVN. To at least make it better, I linked the MINDEXER jira issues to the SVN revisions, so at least we have the JIRA-SVN direction, but SVN commit logs does not point back. http://jira.codehaus.org/browse/MINDEXER-15 http://jira.codehaus.org/browse/MINDEXER-16 http://jira.codehaus.org/browse/MINDEXER-17 http://jira.codehaus.org/browse/MINDEXER-18 Thanks, ~t~ On Wed, Mar 30, 2011 at 12:20 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: I think it would be more appropriate if those commits were mentioning the corresponding MINDEXER issue. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1086889 - /maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/packer/NEXUS4149TransferFormatTest.java
All gitters (like me) having forks would need just a re-fetch again (reinit the git-svn and refetch the svn history). But not sure what will happen with ASF Git mirror? (the git.apache.org/maven-indexer.git one) If you can change svn logs, and you do know the ASF Git mirror will be okay (I dunno), then i'd say go for it. And again, sorry for messing this up :( Thanks, ~t~ On Thu, Mar 31, 2011 at 2:35 AM, Brett Porter br...@apache.org wrote: Would it affect the git history if the svn logs were modified with the updated issue numbers now that it has already been pushed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven ACR Plugin version 1.0
http://www.apache.org/foundation/voting.html On Thu, Mar 31, 2011 at 1:02 PM, Pablo pa...@anahata-it.com wrote: Just curious, What does non binding mean?
Re: [VOTE] Release Maven Indexer version 4.1.0
+1 Thanks, ~t~ (phone) On 31 Mar 2011 22:56, Brian Demers bdem...@apache.org wrote: Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17270 Staging repo: https://repository.apache.org/content/repositories/maven-056/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. Include binding or non-binding along with votes. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.1.0
Hi Hervé, issues created MINDEXER-23 MINDEXER-24 Thanks for spotting these! ~t~ On Sun, Apr 3, 2011 at 10:35 AM, Hervé BOUTEMY herve.bout...@free.frwrote: but I have a few (non-blocking) remarks: - a description should be defined in each pom.xml (actually description is inherited from Maven parent pom) - the site should be published: [1]? tell me if I can help Regards, Hervé [1] http://maven.apache.org/maven-indexer
Re: [VOTE] Release Maven Surefire 2.8.1
+1 Thanks, ~t~ On Tue, Apr 12, 2011 at 3:32 PM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release surefire 2.8.1 We fixed 7 issues : http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17221 Staged repo : https://repository.apache.org/content/repositories/maven-081 Staging sites : * http://maven.apache.org/surefire-2.8.1 (wait sync) * http://maven.apache.org/plugins/maven-surefire-plugin-2.8.1 (wait sync) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Julia Antonova/Tumlare is out of office.
Woo Hoo! Can someone update the wiki please, I am at my phone... Thanks, ~t~ (phone) On Fri, May 6, 2011 at 10:43 PM, Julia Antonova juli...@tumlare.com wrote: I will be out of the office starting 06.05.2011 and will not return until 10.05.2011. I have no acces to my mailbox, I will reply to your message upon return. Thank you!
CI job for Maven Indexer unable to deploy
Hi there, according to [1], the build of Indexer with latest changes went fine, but the deployment to RAO failed with 401. Could someone take a peek and verify the CI job's settings.xml? I don't have the needed karma it seems... [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer/8/console Thanks, ~t~
Re: CI job for Maven Indexer unable to deploy
Um, rollback this below, next builds just deployed fine. O_o https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer/9/ Thanks, ~t~ 2011/6/9 Tamás Cservenák ta...@cservenak.net Hi there, according to [1], the build of Indexer with latest changes went fine, but the deployment to RAO failed with 401. Could someone take a peek and verify the CI job's settings.xml? I don't have the needed karma it seems... [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-indexer/8/console Thanks, ~t~
[VOTE] Release Maven Indexer version 4.1.1
Hi, Current 4.1.1 version is mostly bugfix release for latest 4.0.1 improving indexer robustness, lessen unnecessary IO burden and smaller POM fixes regarding site publishing. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17410 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MINDEXER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-060/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.1.1
Sorry, I meant to say Current 4.1.1 version is mostly bugfix release for latest 4.1.0, NOT 4.0.1. 2011/6/9 Tamás Cservenák ta...@cservenak.net: Current 4.1.1 version is mostly bugfix release for latest 4.0.1 improving indexer robustness, lessen unnecessary IO burden and smaller POM fixes regarding site publishing. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Indexer version 4.1.1
Hi, The vote has passed with the following result : +1 (binding): Mark Struberg, Hervé Boutemy, Olivier Lamy, Brett Porter +1 (non binding): Jesse Glick, Brian Demers, Damian Bradicich I will promote the artifacts to the central repo. Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: why Maven 3 is divided into eleven eclipse project?
Sorry, did not noticed the OOM in the logs! Bot restarted, try again please... Thanks, ~t~ On Wed, Jun 29, 2011 at 9:34 PM, Wendy Smoak wsm...@gmail.com wrote: On Wed, Jun 29, 2011 at 2:36 PM, Martin Gainty mgai...@hotmail.com wrote: make ¢? No. Where did that list come from? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PlexusContainer#lookupList(role) returns only one component
In plexus role+hint forms a composite key. In your case, you had a component conflict, and Plexus stashed one component over another (it's undefined which wins, but probably depends on classpath ordering or so). If you want Plexus to manage them as two distinct components, you have to make them have two distinct keys, hence role+hint must differ on them. BTW, which plexus are you using? The classic (oldie) or the SISU-plexus-shim? Thanks, ~t~ On Tue, Aug 2, 2011 at 11:38 AM, bernd.v...@bosch-si.com wrote: Hello Everybody, I just noticed that PlexusContainer#lookupList(role) will only return a list with one component even there are two components available for the role. After playing around I figured out that the method returns a list with both components when I use different hints in my component descriptors. Is there a way to gather all components of a specific role regardless of their hints (and even if the hints are equal)? I'd like to use that to realize some kind of whiteboard pattern. Regards, Bernd - 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
Re: PlexusContainer#lookupList(role) returns only one component
Inline. On Tue, Aug 2, 2011 at 12:05 PM, bernd.v...@bosch-si.com wrote: In plexus role+hint forms a composite key. In your case, you had a component conflict, and Plexus stashed one component over another (it's undefined which wins, but probably depends on classpath ordering or so). Sure, I expected this behavior for the simple lookup methods which only returns one component but not for the lookupList methods... I hoped I could use this to get all registered components (as I'm used to from other IoCs). The plexus component registry is keyed like this, so I _think_ you cannot do this with Plexus. Is it possible to use guice directly in a SISU-plexus-shim environment? Yes, you can still use Module and other nifty things More about SISU here: http://sisu.sonatype.org/index.html Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1158917 - in /maven/indexer/trunk/indexer-core/src: main/java/org/apache/maven/index/DefaultSearchEngine.java test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java
Hi Olivier,
the change
http://svn.apache.org/viewvc?view=revisionrevision=1158917
while properly fixing the stuff mentioned in commit log, sneaks in
another change that is wrong.
The searchFlat can return empty results with multiple index if the
first used returns empty result fix is okay, and I agree with it
(removal of return 0).
But, what is sneaked in wrt duplicates is wrong, and would violate
and even prevent some existing use cases. The passed in parameter
CollectionArtifactInfo is already a Set with proper Comparator that
is user selectable. In short, you set ArtifactInfo.VERSION_COMPARATOR
always, but that's maybe not what user wants.
To demonstrate, along with fix for your rev1158917 (it undoes that
solution with a Set) I committed an extensive UT demonstrating what
your fix was breaking (just re-implement your change wrt duplicates
and run the UT, will fail).
Never forget that Maven Indexer is not used in MRMs only, things like
IDE integrations are using it too, and those use cases are wildly
different from those used in MRMs.
The change is r1159159
http://svn.apache.org/viewvc?view=revisionrevision=1159159
Thanks,
~t~
On Wed, Aug 17, 2011 at 11:16 PM, ol...@apache.org wrote:
Author: olamy
Date: Wed Aug 17 21:16:25 2011
New Revision: 1158917
URL: http://svn.apache.org/viewvc?rev=1158917view=rev
Log:
[MINDEXER-38] searchFlat can return empty results with multiple index if the
first used returns empty result
Modified:
maven/indexer/trunk/indexer-core/src/main/java/org/apache/maven/index/DefaultSearchEngine.java
maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java
Modified:
maven/indexer/trunk/indexer-core/src/main/java/org/apache/maven/index/DefaultSearchEngine.java
URL:
http://svn.apache.org/viewvc/maven/indexer/trunk/indexer-core/src/main/java/org/apache/maven/index/DefaultSearchEngine.java?rev=1158917r1=1158916r2=1158917view=diff
==
---
maven/indexer/trunk/indexer-core/src/main/java/org/apache/maven/index/DefaultSearchEngine.java
(original)
+++
maven/indexer/trunk/indexer-core/src/main/java/org/apache/maven/index/DefaultSearchEngine.java
Wed Aug 17 21:16:25 2011
@@ -164,17 +164,27 @@ public class DefaultSearchEngine
{
int hitCount = 0;
+ SetArtifactInfo nonDuplicateResults = new TreeSetArtifactInfo(
ArtifactInfo.VERSION_COMPARATOR );
+
+
for ( IndexingContext context : participatingContexts )
{
final TopScoreDocCollector collector = doSearchWithCeiling( req,
context.getIndexSearcher(), query );
+ // olamy if the first context used doesn't find the other are
not used for search
+ // so the result can probably returns duplicate as artifactInfo
doesn't implements hashCode/equals
+ // so implements this in nonDuplicateResults
+ /*
if ( collector.getTotalHits() == 0 )
{
return 0;
}
+ */
ScoreDoc[] scoreDocs = collector.topDocs().scoreDocs;
+ // uhm btw hitCount contains dups
+
hitCount += collector.getTotalHits();
int start = 0; // from == FlatSearchRequest.UNDEFINED ? 0 : from;
@@ -192,11 +202,14 @@ public class DefaultSearchEngine
artifactInfo.context = context.getId();
- result.add( artifactInfo );
+ nonDuplicateResults.add( artifactInfo );
+
}
}
}
+ result.addAll( nonDuplicateResults );
+
return hitCount;
}
Modified:
maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java
URL:
http://svn.apache.org/viewvc/maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java?rev=1158917r1=1158916r2=1158917view=diff
==
---
maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java
(original)
+++
maven/indexer/trunk/indexer-core/src/test/java/org/apache/maven/index/SearchWithAnEmptyIndexTest.java
Wed Aug 17 21:16:25 2011
@@ -31,6 +31,7 @@ import org.codehaus.plexus.util.FileUtil
import java.io.File;
import java.util.ArrayList;
+import java.util.Arrays;
import java.util.List;
/**
@@ -70,10 +71,9 @@ public class SearchWithAnEmptyIndexTest
}
}
- public void testWithTwoContextWithOneEmpty()
+ public void testWithTwoContextWithOneEmptyFirstInContextsListSearchFlat()
throws Exception
{
- createIndex( src/test/repo-with-osgi,
target/test/repo-with-osgi/, INDEX_ID1 );
String repoPath = target/test/empty-repo-for-searchtest;
@@ -89,6 +89,8 @@ public class SearchWithAnEmptyIndexTest
Re: [VOTE] Release Maven Archetype Plugin version 2.1
+1 On Wed, Aug 31, 2011 at 9:39 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Hi, We solved 24 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095styleName=Htmlversion=16795 There are still a good number of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11095status=1 Staging repo: https://repository.apache.org/content/repositories/maven-006/ Staging site: (sync pending) http://maven.apache.org/archetype-2.1/maven-archetype-plugin/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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
Re: [VOTE] Release Apache Maven Indexer 4.1.2
Oups, sorry for the delay: +1 On Wed, Sep 21, 2011 at 10:26 AM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven Indexer 4.1.2. We fixed 5 issues : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MINDEXER+AND+fixVersion+%3D+%224.1.2%22+AND+status+%3D+Closed+ORDER+BY+priority+DESCmode=hide . Staging repo : https://repository.apache.org/content/repositories/maven-085/ Staging site : http://maven.apache.org/maven-indexer-4.1.2 (wait sync ) [+1] [0] [-1] Here my +1. Thanks, -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire version 2.10
+1 On Tue, Sep 27, 2011 at 12:26 AM, Paul Gier pg...@apache.org wrote: Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541version=17431 There are still lots of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-107/ Staging site: (Sync pending) http://maven.apache.org/surefire-2.10/ http://maven.apache.org/plugins/maven-failsafe-plugin-2.10/ http://maven.apache.org/plugins/maven-surefire-plugin-2.10/ http://maven.apache.org/plugins/maven-surefire-reports-plugin-2.10/ SCM Tag: http://svn.apache.org/repos/asf/maven/surefire/tags/surefire-2.10/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Wagon 2.0
+1 On Mon, Sep 26, 2011 at 3:56 PM, Olivier Lamy ol...@apache.org wrote: Hello, I'd like to release Apache Maven Wagon 2.0. We fixed 31 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=17379styleName=TextprojectId=10335Create=Create Staging repo : https://repository.apache.org/content/repositories/maven-104/ Staging site : http://maven.apache.org/wagon-2.0 (wait sync). [+1] [ 0] [-1] An easy way to test it: download jar and put it your $M2_HOME/lib/ext (if you use maven 3). wagon http: wget https://repository.apache.org/content/repositories/maven-104/org/apache/maven/wagon/wagon-http/2.0/wagon-http-2.0-shaded.jar cp wagon-http-2.0-shaded.jar $M2_HOME/lib/ext/ Here my +1. Thanks, -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Use aether 1.13 and sisu 2.3.0 as dependencies of Apache Maven
+1 Thanks, ~t~ (phone) On Nov 10, 2011 4:53 PM, Olivier Lamy ol...@apache.org wrote: Hello, Since last vote things have changed: * aether is in incubation process @eclipse * sisu is in incubation process @eclipse Due to the fact that those process can be long before having an official release from eclipse namespace, some new features are blocked. I propose to upgrade to: * aether 1.13 * sisu 2.3.0 Note: when a release will be available @eclipse, we will upgrade to this release. The technical details can be discussed later especially if we need to do some package changes. [+1] I'm in favor of this upgrade and the other upgrade when release will be available under eclipse.org governance [+0] I don't care, do what you want. [-1] I'm against because (please explain) The vote open is open for 6 days as we are near week end (with maybe bank holidays in some countries) and some people have too much beer in ApacheCon :-). Here my +1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven 3.0.4
Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy(AbstractDeployMojo.java:167) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:149) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at
Re: [VOTE] Apache Maven 3.0.4
Out of curiosity, why is chunked transfer encoding used to transfer the few byte long SHA1 string? Personally, I'd avoid the use of chunked whenever possible, since -- just like this example shows -- many servers does not support it completely... Thanks, ~t~ On Tue, Nov 29, 2011 at 1:21 PM, Olivier Lamy ol...@apache.org wrote: Thanks. That's what I have seen. Content-Lenght is null because chunked is used. I will enhance core it to ensure Content-Length header is correct and update wagon http to fix that. BTW canceling a release because a http server does not support chunck is a pain 2011/11/29 Tamás Cservenák ta...@cservenak.net: Hi, Nexus does not respond with HTTP 411. It has to be some nexus-fronting app (httpd or nginx?) And I am 99% confident that according to RFC[1], this was a case of incomplete request or such. As I inspected, nexus@codehaus is fronted by nginx 0.8.24 By googling, I found this: http://www.lamnk.com/blog/computer/fix-nginx-411-length-required-error/ [1] http://tools.ietf.org/html/rfc2616 Thanks, ~t~ On Tue, Nov 29, 2011 at 12:35 PM, Olivier Lamy ol...@apache.org wrote: Agree I will cancel the vote to investigate more. I wonder why it works when deploying maven scm to repository.apache.org and tested on a locally installed nexus instance ? Can nexus folks who are listening here explains to me in which case this happen http Return code: 411, ReasonPhrase:Length Required. Bad or empty Content-Length http header ? 2011/11/29 Mark Struberg strub...@yahoo.de: I think delivering artifacts without md5 and sha1 is pretty much a blocker as this might introduce security issues along the line. So I'd say we investigate further before we go ahead. Thus I change my vote to a -1 (binding) also. We now have a few cases which work well and a few cases which cause this error. Means we have to check where the difference is. LieGrue, strub - Original Message - From: Anders Hammar and...@hammar.net To: Maven Developers List dev@maven.apache.org Cc: Sent: Tuesday, November 29, 2011 11:14 AM Subject: Re: [VOTE] Apache Maven 3.0.4 I see the same checksum issue when trying to deploy a snapshot over at Codehaus mojo: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/jboss-packaging-maven-plugin/2.3-SNAPSHOT/ I'm changing my vote to -1 (non-binding). IMHO we do not want end user issues due to something like this. /Anders On Tue, Nov 29, 2011 at 11:09, Stephen Connolly stephen.alan.conno...@gmail.com wrote: That stacktrace was with extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version2.1/version /extension /extensions in the pom... if I try extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-http/artifactId version1.0/version /extension /extensions I get [DEBUG] Using connector WagonRepositoryConnector with priority 0 for https://nexus.codehaus.org/service/local/staging/deploy/maven2/ as stephenconnolly Uploading: https://nexus.codehaus.org/service/local/staging/deploy/maven2/org/codehaus/mojo/mrm/1.0-alpha-1/mrm-1.0-alpha-1.pom Nov 29, 2011 10:06:08 AM org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme INFO: basic authentication scheme selected [DEBUG] Failed to upload SHA-1 checksum for /Users/stephenc/codehaus/mrm/target/checkout/pom.xml: Should not be using the streaming wagon for HTTP PUT java.lang.IllegalStateException: Should not be using the streaming wagon for HTTP PUT at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:692) at org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272) at org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818) at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274) at org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137) at org.apache.maven.plugin.deploy.AbstractDeployMojo.deploy
Re: [CALL FOR TEST] Apache Maven 3.0.4-RC3 staged
Same for MRMs, to perform checksum/signature/content analysis... to be able to cleanly refuse maven when asking for broken artifact (and having checksum/signature/content validation on). Otherwise, if would be done while streaming, currently there's no clean way to say to client (Maven) at _the end_ of streaming: ah, this is bad content, throw it away... Thanks, ~t~ On Tue, Dec 13, 2011 at 9:24 AM, Anders Hammar and...@hammar.net wrote: As someone pointed out, in most corporate environments downloads are scanned by AV engines. And that means that the entire file needs to be downloaded by that engine and then scanned, before made available to the repo manager. So this isn't something that the repo manager could fix. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Indexer, filter by period of time and classNames field
Your example accesses Central Repository Index (http://repo1.maven.org/maven2), and due to bandwidth considerations, it does NOT index, hence index chunks you download does not have classNames in it. Otherwise, your code looks good. Try the same against a Nexus repository with some JARs deployed, it will work. In short, Central repository uses min and maven-plugin set of creators, while Nexus uses full set of index creators. you can use Luke http://www.getopt.org/luke/ to inspect what downloaded index actually contains min is the bare minimum, and is always present, while others are optional creators. Hope helps, ~t~ On Tue, Apr 17, 2012 at 9:11 AM, Laurent Pellegrino laurent.pellegr...@gmail.com wrote: Hi all, I am trying to use Apache maven indexer to retrieve artifacts whose for example their lastModified field indicates a date between January and February of this year (1). Then, for each artifact retrieved, I would like to get the classNames field value (2). To achieve it I tried to use the API provided with Maven indexer and the Lucene API but with both methods it seems impossible to fullfill requirements (1) and (2) at the same time. By using the Maven indexer API (c.f. [1]) I retrieve artifacts for the desired period of time but when I access to the field classNames I get null instead of the right value for artifacts with packaging of type JAR. However, I have specified a JarFileContentsIndexCreator for indexers. Is there a bug during reconstruction of artifacts info, is it a correct behavior or do I miss something? My second idea was to use directly Lucene to retrieve what I need but according to the implementation MinimalArtifactInfoIndexCreator declares the field lastModified (FLD_LAST_MODIFIED) as being not indexed. Thus, it is impossible to perform a search by using the efficient NumericRangeFilter predicate. Moreover, in terms of execution time this method would be better than the first solution that uses an ArtifactFilter which is iteratively applied among all the documents. Is it not possible to index this field? More generally, does someone has a method to achieve requirement (1) and (2)? [1] http://pastebin.com/raw.php?i=qaNXjWT5 Thanks. Kind Regards, Laurent - 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 Indexer Changes
Hi there, Olivier did a great job of releasing Maven Indexer 4.1.3 that bumped Lucene to 3.6.1. But, having Lucene 3.6.1 in MI makes us now possible to do more. Here is a branch I did today: https://github.com/cstamas/maven-indexer/commits/fixes Basically, it has following changes: * Removed heavy uses of StringBuffer, replaced with StringBuilder * Version bumped to 4.5.0-SNAP (from 4.1.4-SNAP) as changes below introduces API breakage (especially how you acquire IndexSearcher from context, needed to properly implement locking semantics) * Removed bottle warmer threads completely * Removed problematic locking around contexts as we rely now on Lucene * Using new SearcherManager (see http://blog.mikemccandless.com/2011/09/lucenes-searchermanager-simplifies.html) instead of doing all this manually + relying on those removed stuff above * Removed deprecated baggage Changes above renders issues MINDEXER-52 and alike actually a non-issues. Please comment the changes. Thanks, ~t~
Re: Maven Indexer Changes
It's something not needed when you are breastfeeding :p Thanks, ~t~ mobile On Aug 8, 2012 8:07 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Exactly what is a Bottle warmer thread ?? I think I want one too ;) Kristian 2012/8/7 Tamás Cservenák ta...@cservenak.net: Hi there, Olivier did a great job of releasing Maven Indexer 4.1.3 that bumped Lucene to 3.6.1. But, having Lucene 3.6.1 in MI makes us now possible to do more. Here is a branch I did today: https://github.com/cstamas/maven-indexer/commits/fixes Basically, it has following changes: * Removed heavy uses of StringBuffer, replaced with StringBuilder * Version bumped to 4.5.0-SNAP (from 4.1.4-SNAP) as changes below introduces API breakage (especially how you acquire IndexSearcher from context, needed to properly implement locking semantics) * Removed bottle warmer threads completely * Removed problematic locking around contexts as we rely now on Lucene * Using new SearcherManager (see http://blog.mikemccandless.com/2011/09/lucenes-searchermanager-simplifies.html ) instead of doing all this manually + relying on those removed stuff above * Removed deprecated baggage Changes above renders issues MINDEXER-52 and alike actually a non-issues. Please comment the changes. Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Indexer Changes
In short: Java6 EOL is coming in months now, users running 1.5 and below should really consider an upgrade. A bit longer: Java6 1st release happened in 2006, 6 years ago. In our profession, that is around 70 years old, 6 years corresponds to -- for example in optics (first known lenses are about 700 BC according to wikipedia) -- to roughly 233 years. So, in case you wear spectacles, would you wear these today http://www.sptddog.com/sotp/18thcent.jpg ? In essence: not really needed for now, as Lucene 3.6.1 is fine on Java5, and IOEx new constructor is used in very few places but we can go back in time for 233 years for now. Thanks, ~t~ On Wed, Aug 8, 2012 at 7:24 PM, Robert Scholte rfscho...@apache.org wrote: What's the reason for the Bumped MI to Java6 level.? Looks like a potential issue to me (assuming a lot of projects still use java5) -Robert Op Wed, 08 Aug 2012 18:29:41 +0200 schreef Olivier Lamy ol...@apache.org : Nice changes. +1 to merge that. Maybe some jiras entries to create :-) -- Olivier Le 7 août 2012 23:21, Tamás Cservenák ta...@cservenak.net a écrit : Hi there, Olivier did a great job of releasing Maven Indexer 4.1.3 that bumped Lucene to 3.6.1. But, having Lucene 3.6.1 in MI makes us now possible to do more. Here is a branch I did today: https://github.com/cstamas/**maven-indexer/commits/fixeshttps://github.com/cstamas/maven-indexer/commits/fixes Basically, it has following changes: * Removed heavy uses of StringBuffer, replaced with StringBuilder * Version bumped to 4.5.0-SNAP (from 4.1.4-SNAP) as changes below introduces API breakage (especially how you acquire IndexSearcher from context, needed to properly implement locking semantics) * Removed bottle warmer threads completely * Removed problematic locking around contexts as we rely now on Lucene * Using new SearcherManager (see http://blog.mikemccandless.**com/2011/09/lucenes-** searchermanager-simplifies.**htmlhttp://blog.mikemccandless.com/2011/09/lucenes-searchermanager-simplifies.html ) instead of doing all this manually + relying on those removed stuff above * Removed deprecated baggage Changes above renders issues MINDEXER-52 and alike actually a non-issues. Please comment the changes. Thanks, ~t~ --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Indexer Changes
Ok. As I said, java6 is not a must. Will be undone and merge prepared. Thanks, ~t~ mobile On Aug 9, 2012 4:14 AM, Chris Graham chrisgw...@gmail.com wrote: Whilst Java6 may be soon coming to EOL, I am still supporting many large corporates on Java 1.4 - corporates do not necessarily move quickly - not if their solution works. Just something to consider from the real world. -Chris Sent from my iPhone On 09/08/2012, at 1:13 AM, Tamás Cservenák ta...@cservenak.net wrote: In short: Java6 EOL is coming in months now, users running 1.5 and below should really consider an upgrade. A bit longer: Java6 1st release happened in 2006, 6 years ago. In our profession, that is around 70 years old, 6 years corresponds to -- for example in optics (first known lenses are about 700 BC according to wikipedia) -- to roughly 233 years. So, in case you wear spectacles, would you wear these today http://www.sptddog.com/sotp/18thcent.jpg ? In essence: not really needed for now, as Lucene 3.6.1 is fine on Java5, and IOEx new constructor is used in very few places but we can go back in time for 233 years for now. Thanks, ~t~ On Wed, Aug 8, 2012 at 7:24 PM, Robert Scholte rfscho...@apache.org wrote: What's the reason for the Bumped MI to Java6 level.? Looks like a potential issue to me (assuming a lot of projects still use java5) -Robert Op Wed, 08 Aug 2012 18:29:41 +0200 schreef Olivier Lamy ol...@apache.org : Nice changes. +1 to merge that. Maybe some jiras entries to create :-) -- Olivier Le 7 août 2012 23:21, Tamás Cservenák ta...@cservenak.net a écrit : Hi there, Olivier did a great job of releasing Maven Indexer 4.1.3 that bumped Lucene to 3.6.1. But, having Lucene 3.6.1 in MI makes us now possible to do more. Here is a branch I did today: https://github.com/cstamas/**maven-indexer/commits/fixes https://github.com/cstamas/maven-indexer/commits/fixes Basically, it has following changes: * Removed heavy uses of StringBuffer, replaced with StringBuilder * Version bumped to 4.5.0-SNAP (from 4.1.4-SNAP) as changes below introduces API breakage (especially how you acquire IndexSearcher from context, needed to properly implement locking semantics) * Removed bottle warmer threads completely * Removed problematic locking around contexts as we rely now on Lucene * Using new SearcherManager (see http://blog.mikemccandless.**com/2011/09/lucenes-** searchermanager-simplifies.**html http://blog.mikemccandless.com/2011/09/lucenes-searchermanager-simplifies.html ) instead of doing all this manually + relying on those removed stuff above * Removed deprecated baggage Changes above renders issues MINDEXER-52 and alike actually a non-issues. Please comment the changes. Thanks, ~t~ --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org 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
Re: Maven Indexer Changes
Brett and others, I rolled back MI to Java5, but I agree, due to API breakage I did bump the version to 5.0.0-SNAPSHOT. https://github.com/cstamas/maven-indexer/commits/fixes As for consumer side code, few examples: Maven Indexer Examples updated to represent needed changes (commented on API changes for clarity sake, but I had some reformats happening too, sorry for that): https://github.com/cstamas/maven-indexer-examples/commit/eb38e442889d072d380c8fb18e5f35a5dd372076 Other example might be Nexus itself, here is a branch (from yesterday, where MI version is still 4.5.0-SNAP but API is already the same as in 5.0.0-SNAP): https://github.com/sonatype/nexus/commit/e8301d4cf93b7dba5d10988124696262b1786433 As you see, the API breakage actually depends very much on how you use MI, as for example Nexus code _had no changes_ (only one UT doing low-level stuff to bring index into some specific state). If you did not tamper with low level access of it by using IndexSearcher directly, you might be lucky and need no change at all :) Thanks, ~t~ On Thu, Aug 9, 2012 at 2:33 AM, Brett Porter br...@apache.org wrote: I don't have a problem with updating it if there's something useful to take advantage of, knowing the user-base of the library. In other libraries, we don't need to upgrade just for the sake of it, of course. Perhaps with this requirement, and the API breakage you indicated, the version could bump to 5.0.0-SNAPSHOT? I like the semantic versioning rules ( semver.org).
Re: Git as the canonical SCM
+1000 and don't forget one of the simplest: maven-indexer (my guts always tremble when I need to dcommit there, due to stupid eu/us git-svn problems) :D Thanks, ~t~ On Wed, Sep 5, 2012 at 11:41 AM, Arnaud Héritier aherit...@gmail.comwrote: +1 to do it step by step The conversion is easy for projects having already a dedicated trunk/tags/branches entry in SVN It will be less funny for plugins but possible. I'm also in favor to split per project/lifecycle even if it is creating a lot of repositories The problem to loose the plugins reactor is for me a problem only for CI and it may be the opportunity for us to think to add the feature of modules described per GAV and automatically checked out from the SCM :-) For the ability for a developer to clone all repo (an operation we are doing only once) we may have a shell script or something like that if we don't have something better from infra side. (or we clone their copies from github and its easy with few lines of ruby or something like that) Cheers, On Wed, Sep 5, 2012 at 9:31 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think we should move to git; probably starting with a few repositories. I will not go into the argument as to why (it's been covered like a zillion times, link by Andrew covers a lot of it), other than to mention that the immense ease of moving around in history means that I never have to consider a patch stale since I can easily review it at the point in history it was created; additionally there's a much-improved chance I can move this to the top of history without being stale) Basically I've been meaning to start av vote suggesting that we: 1) Decide to move *all* maven projects to git, time frame subject to project/asf/infra capacity. We're in no immense hurry. 2) Kick off the effort by moving 2-3 projects initially, 1-2 easy ones (just to get the general feel for how things work) and a hard one. Right now I'd suggest something like m3-core, surefire( or scm) and maven-plugins, the last being the hard one ;) I herby volunteer to do the donkey-work, including some massive filter-branch operations on the current asf maven-plugins git clone. I think we should split maven-plugins, because I think the solution chosen is optimized for the wrong uses cases, and it only helps for setting up CI jobs. The rest of the community basically has no value in the current set-up. Which makes me think we should consider such a switch an opportunity to re-think some of our tooling around multi-module projects. What the 99% others want (who're not setting up a CI) is a checkout algorithm that builds the *vertical* stack for a given plugin, not the horizontal top-level stack for all the plugins (which is what we have currently). So if I checkout maven-ear-plugin, I would basically want something like this: root-dir\ maven-ear-plugin\ maven-archiver\ maven-filtering\ plexus-archiver\ plexus-utils .. maybe more.. (probably configurable somewhere) Now if the checkout would generate a synethetic parent pom with all these as modules, I could just load it all up in IDEA and be ready to go. I think something like this would have /real/ value to most of our users, whereas the current maven-plugins layout really only is valuable for whoever is configuring a CI to build maven-plugins. No matter what, I think there's very lfew practical use cases for having all the modules chunked together. Kristian 2012/9/4 Olivier Lamy ol...@apache.org: 2012/9/4 Andrew Waterman awate...@ecosur.mx: The drools guys did a really nice move from Subversion a few years back. http://blog.athico.com/2010/12/drools-migrated-to-git.html One of the key things they did, was reorganize their poms and project structure. I'd be willing to help out. I think there could be a lot more to this move than just importing from subversion, but it depends on what you guys want to do. Yup I agree. I use git on other oss projects (Apache: cloudstack and non Apache: jenkins ...) and git svn for some asf projects. Due to lack of support of sparse checkout in git, I (perso) don't want we have to create a git repo per plugin etc... IMHO That will be a pain to manage. best wishes, Andrew On Sep 4, 2012, at 3:09 PM, Jason Pyeron jpye...@pdinc.us wrote: -Original Message- From: Jason van Zyl Sent: Tuesday, September 04, 2012 15:55 How's Git doing at Apache these days? Anyone interested in pursuing putting Maven in Git as the canonical SCM? Comments from the peanut gallery: It would make it very nice to contribute back. Since I do not have a sandbox access I have thrown away fixes because there was no efficient way to track them until they were accepted as patches. (same problem in struts, commons, ...) We would be very happy here at
Re: Dynamically determining the currently executing goal name
Add following member to your Mojo and inspect what is injected:
/**
* Mojo execution.
*
* @parameter default-value=${mojoExecution}
* @required
* @readonly
*/
private org.apache.maven.plugin.MojoExecution mojoExecution;
Hope helps,
~t~
On Mon, Sep 10, 2012 at 6:59 PM, Jeff Maxwell jeff.maxw...@gmail.comwrote:
I would like to dynamically determine the currently executing goal from a
MOJO.
I attempted this using reflection but the new annotations are not available
at runtime.
All other solutions I have seen appear to require access to the executing
MOJO's groupId and artifactId.
Anyone have a solution?
Is there an issue with having the annotations available at runtime?
--
View this message in context:
http://maven.40175.n5.nabble.com/Dynamically-determining-the-currently-executing-goal-name-tp5721050.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
Release of Maven Indexer 5.0
Howdy, there are a notable changes in trunk of MI: https://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MINDEXER+AND+fixVersion+%3D+%225.0.0%22+AND+status+%3D+Closed+ORDER+BY+priority+DESC https://github.com/apache/maven-indexer/commits/trunk?page=1 So, I'd like to spin a release of it. Any objections to this? Any last minute wish? Thanks, ~t~
