Re: Maven Docker Images
On Sat, Oct 21, 2017 at 3:56 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > notice that we vote on source tarballs, not really on binary artifacts > > I see the git source changes, both in Dockerfiles and in official-images > library/ > maven. > But I don't see when/how images are built > > can you explain, please? > Docker inc. triggers the builds after git changes in https://github.com/docker-library/official-images but could also rebuild whenever they want > > Regards, > > Hervé > > Le samedi 21 octobre 2017, 10:59:45 CEST Carlos Sanchez a écrit : > > BTW there are possibly more than one image build for each maven version. > > For a variety of reasons, like security issues in OS or to upgrade JDK or > > because docker rebuilds it, so it is not feasible to vote each of them. > > > > On Sat, Oct 21, 2017, 12:33 Robert Scholte <rfscho...@apache.org> wrote: > > > On Sat, 21 Oct 2017 12:19:46 +0200, Hervé BOUTEMY < > herve.bout...@free.fr> > > > > > > wrote: > > > > Le samedi 21 octobre 2017, 08:16:35 CEST Stephen Connolly a écrit : > > > >> On Sat 21 Oct 2017 at 08:45, Hervé BOUTEMY <herve.bout...@free.fr> > > > >> > > > >> wrote: > > > >> > ok, let's switch directly to the Docker case > > > >> > > > > >> > I'm not a Docker expert, then I'm discovering things that my be > > > >> > > > >> obvious to > > > >> > > > >> > others > > > >> > > > > >> > IIUC Docker has an "officiel images" project [1] where Carlos > > > >> > > > >> provided a > > > >> > > > >> > Maven > > > >> > image [2]: then this image is known as "the official Maven Docker > > > >> > > > >> image" > > > >> > > > >> > Carlos is an individual, he's also a PMC member of Maven > > > >> > > > > >> > what do we want to say: the PMC member has provided an official > > > >> > Docker > > > >> > image or > > > >> > an individual has provided an official Docker image? > > > >> > > > > >> > depending on the answer, some way of doing has to be changed (Git > > > >> > > > >> location > > > >> > > > >> > or > > > >> > naming of the official image) > > > >> > > > >> I’m in favour of creating a repo for the dockerfile, license.txt, > read > > > >> me, > > > >> notices, etc > > > > > > > > ok, here I follow > > > > > > > >> and follow the standard release vote lifecycle for that > > > >> dockerfile. > > > > > > > > here, I'm not sure this really has a meaning in these official Docker > > > > images > > > > cases: IIUC, on a new Maven core release that we want to promote, > there > > > > are 2 > > > > actions that are required: > > > > 1. modify the MAVEN_VERSION and SHA values in */Dockerfile in the git > > > > repo [1] > > > > 2. have a PR merged to Docker official-images to update the sha1 in > > > > official- > > > > images/library/maven [2] > > > > > > > > Between the 2 steps, we can choose to vote, or not to vote, I don't > know > > > > what's the best: we already voted for the Maven release that gets the > > > > new > > > > recommended version. > > > > What is important to me is that anybody from the PMC can do the PR to > > > > Docker > > > > official-images (if we decide that we maintain the official image, > not > > > > only > > > > Carlos): there is not specific credentials > > > > > > > > One thing I see is that we can automate a check that the current > > > > official-image > > > > is our currently recommended Maven version: it's just about adding a > new > > > > check > > > > to dist-tool-plugin that will be checked every day by Jenkins job [3] > > > > > > Without talking in solutions, we have this general question: Are we > > > informing others by their format or are we offering some generic > message > > > for others to make them aware there's a new version. > > > > > > This disttool solution sounds like the first one (we tr
Re: Maven Docker Images
s, > >> > > >> > Hervé > >> > > >> > [1] https://github.com/docker-library/official-images > >> > > >> > [2] > >> > > >> > https://github.com/docker-library/official-images/blob/master/library/mave > >> > n > >> > > >> > Le samedi 21 octobre 2017, 06:58:50 CEST Manfred Moser a écrit : > >> > > From my perspective it is just like sdkman including the > >> conclusion. We > >> > > >> > have > >> > > >> > > other tasks at our hands, maintaining a docker images is not > >> something > >> > > we > >> > > should bother with. However needs one can easily create one and > >> there > >> > > >> > will > >> > > >> > > be thousands of variations different users want. > >> > > > >> > > Let them create it on their own. > >> > > > >> > > Manfred > >> > > > >> > > Hervé BOUTEMY wrote on 2017-10-20 18:46: > >> > > > true, from a general perspective, it's like sdkman > >> > > > > >> > > > we need to discuss then decide if we want to maintain Maven Docker > >> > > > integration (contrary to our current decision to not maintain > >> Maven > >> > > > sdkman integration but let sdkman community do it) > >> > > > > >> > > > can we think about a general solution? perhaps not really a > >> solution, > >> > > >> > but > >> > > >> > > > a > >> > > > decision process, yes > >> > > > > >> > > > to me, on each tool integration, there are key decision drivers: > >> > > > - importance of the tool on the market > >> > > > - interest of Maven devs to actually do integration maintenance > >> > > > - complexity of integration, technical prerequisites (with IDEs, > >> for > >> > > > example, a dedicated independant project like m2e is necessary) > >> > > > - time factor: things evolve over time (e.g. 2 years ago, Docker > >> was > >> > > >> > not > >> > > >> > > > what it is nowadays) > >> > > > > >> > > > any other key driver to document? > >> > > > > >> > > > once done, we'll discuss more precisely about the Docker > >> integration > >> > > >> > case > >> > > >> > > > and probably finish with a vote :) > >> > > > > >> > > > Regards, > >> > > > > >> > > > Hervé > >> > > > > >> > > > Le vendredi 20 octobre 2017, 11:30:49 CEST Robert Scholte a écrit > >> : > >> > > >> Isn't this actually the same case as sdkman[1]? > >> > > >> Just wondering if we need to think about a general solution > >> instead > >> > > >> of > >> > > >> pulling everything into our project when possible. > >> > > >> > >> > > >> thanks, > >> > > >> Robert > >> > > >> > >> > > >> [1] http://markmail.org/message/oofvszmf56tbr7et > >> > > >> > >> > > >> On Thu, 19 Oct 2017 19:30:57 +0200, Hervé BOUTEMY < > >> > > >> > herve.bout...@free.fr> > >> > > >> > > >> wrote: > >> > > >> > great idea > >> > > >> > > >> > > >> > ok, we need a git repo at ASF > >> > > >> > > >> > > >> > what else? > >> > > >> > Is there some sort of release process? some sort of source to > >> > > >> > release? > >> > > >> > > >> > Regards, > >> > > >> > > >> > > >> > Hervé > >> > > >> > > >> > > >> > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit : > >> > > >> >> Thanks for the pointer, Carlos! I had searched the archives, > >> but > >> > > >> > maybe > >> > > >> > > >> >> I > >> > > >> >> didn't go back far
Re: Maven Docker Images
Official docker images are not pushed to dockerhub. Docker builds them from sources at GitHub https://github.com/docker-library/official-images/blob/master/library/maven On Fri, Oct 20, 2017, 08:20 Maxim Solodovnik <solomax...@gmail.com> wrote: > I would start with filing INFRA ticket :) > > On Fri, Oct 20, 2017 at 12:40 PM, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: > > > awesome: there is some common practice we should get into > > > > do you know if there some docs somewhere? > > I suppose there are some credentials associated to publishing to > Dockerhub > > > > Regards, > > > > Hervé > > > > Le vendredi 20 octobre 2017, 11:39:22 CEST Maxim Solodovnik a écrit : > > > In this case dockerhub is preferable :) > > > > > > On Fri, Oct 20, 2017 at 11:07 AM, Bindul Bhowmik < > > bindulbhow...@gmail.com> > > > > > > wrote: > > > > Maxim, > > > > > > > > On Thu, Oct 19, 2017 at 7:54 PM, Maxim Solodovnik < > > solomax...@gmail.com> > > > > > > > > wrote: > > > > > Hello, > > > > > > > > > > here is the place for Apache docker images managed by infra and > > Apache > > > > > projects https://bintray.com/apache/ :) > > > > > > > > From what I have seen, while there are 4 projects with docker > > > > repositories on bintray, there seem to be a lot more at dockerhub > [1]. > > > > I did a quick search on INFRA JIRA and found that infra has set a few > > > > projects up on dockerhub recently [2], for example INFRA-14756 [3] > for > > > > bookkeeper. > > > > > > > > Bindul > > > > > > > > [1] https://hub.docker.com/r/apache/ > > > > [2] https://issues.apache.org/jira/issues/?jql=component%20% > > > > 3D%20Docker%20AND%20project%20%3D%20INFRA > > > > [3] https://issues.apache.org/jira/browse/INFRA-14756 > > > > > > > > > On Fri, Oct 20, 2017 at 12:30 AM, Hervé BOUTEMY < > > herve.bout...@free.fr> > > > > > > > > > > wrote: > > > > > > great idea > > > > > > > > > > > > ok, we need a git repo at ASF > > > > > > > > > > > > what else? > > > > > > Is there some sort of release process? some sort of source to > > release? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit : > > > > > > > Thanks for the pointer, Carlos! I had searched the archives, > but > > > > > > > > maybe I > > > > > > > > > > > didn't go back far enough. > > > > > > > > > > > > > > I think moving these Dockerfiles into an ASF repo would be > great > > for > > > > > > > > > > > > their > > > > > > > > > > > > > maintainability. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > On 2017-10-19 03:50, Carlos Sanchez <c...@apache.org> wrote: > > > > > > > > Arnaud is correct, I sent an email to users@ back on Fri, > Nov > > 7, > > > > > > > > > > > > 2014,> > > > > > > > > > > > > > > 00:23 when I created the image> > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier <ah...@gmail.com > > > > > > > > > > wrote:> > > > > > > > > > > > > > These images are kindly managed by a PMC member of our > > project > > > > > > > > > > > > (Carlos) > > > > > > > > > > > > > but> > > > > > > > > > > > > > > > > yes they aren't managed directly by the project> > > > > > > > > > > > > > > > > > > We can easily see with him to improve this IMO.> > > > > > > > > > > > > > > > > > > When he started that (several years ago) Docker wasn'
Re: [DISCUSSION] JEP 238: Multi-Version JAR Files
: I expect we could run the unit test suite on JDK 6 / 7 / 8 in parallel with 7/8 specific code being used for the JDK that do support them, so I wonder such a multi-module setup would work in this scenario, or would need yet another maven module for tests :'( 2015-04-12 23:33 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Le samedi 11 avril 2015 21:42:50 Paul Benedict a écrit : I've been giving this subject lots of thought in some of spare time. IMO, the most straightforward way of meeting the requirement of the MVJAR is to break up one's JAR project into separate modules. One module would contain the version independent code, and then other modules would be per Java version. more precisely: the first module would contain the source for minimum Java version: sometimes, it will contain code that won't run with later JRE This kind of slicing is necessary because you do need different kinds of compiler directives (like -source), different JREs to run unit tests differently, and most importantly, the different JREs to allow debugging according to the Java version you want to test. The other piece that doesn't yet exist is a way to bundle the modules into one jar. Perhaps this can be accomplished by introducing a new mvjar Maven type. I didn't imagine this scenario: no Maven plugins updates nor IDE, just a new feature to merge multiple modules into on MV jar interesting idea, in fact: this would seriously reduce the impact on tooling, even if the result is less compact, ie creates a lot of Maven modules and I am wondering what unit tests will look like for additional versions: the good thing is that they can be tweaked easily. Then bad thing is that we may end up in copy/pasting them Regards, Hervé Paul Cheers, Paul On Sat, Apr 11, 2015 at 9:37 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit : Technically we support main scoped sources in java6 and test scoped sources in java7 today, but the feature is largely unusable since IDE support is totally missing. Even IntelliJ does not support it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues) :( There might be some hope of gaining some kind of traction to both source and main-level support of multi-language-level modules. Maybe something like (src/main/java and src/test/java = default language level) while src/[main|test]/java-8 would be a specific language level. This sounds infinitely cool, yes, that's what I did in plexus-utils jdep-238 branch https://github.com/codehaus-plexus/plexus-utils/tree/jep-238/src/main but also like a great can of worms :) yes, I fear it's not so easy for IDEs... I assume minimum compiler requirement would be java-8 for a project with src/main/java-8 ? yes, I think that's what makes such support hard at the moment: require the highest JDK, and signature for every lower JDK to avoid newer APIs unless JDK 9 can safely compile for any older target, checking the API (without having to run Animal Sniffer after that) Regards, Hervé K 2015-04-11 15:11 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr: Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit : IDE support for multiple source trees seems quite far off ? IDE support for current situation, where we mix multiple Java API versions in one single source tree, is even more far off! With separate source trees, IDE support starts like we are at the moment = no IDE support but IDEs that want to do something about it have a chance: that's the big difference IMHO Regards, Hervé Kristian 2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr Hi, Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier
Re: Apache Maven Developers meet-up at fosdem
I'm going to be there Friday-Sunday too, let me know On Sat, Dec 27, 2014 at 7:21 PM, Robert Scholte rfscho...@apache.org wrote: Hi all, this week I, Hervé and Karl-Heinz decided to visit fosdem[1] this year to meet each other IRL[2]. The decision was way past the deadline of the CfP, so we can't claim a room to talk with our users. The plan is to meet each other on Sunday, February 1st in Brussels. If there are other developers willing to join, please let us know. thanks, Robert [1] https://fosdem.org/ [2] in real life - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Apache Maven Developers meet-up at fosdem
I'm staying near the Bruxelles Central, place du Grand Sablon On Fri, Jan 16, 2015 at 9:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I'm coming there too, provided I can get plane tickets ! Any particular hotels you guys are using ? K 2015-01-16 9:01 GMT+01:00 Carlos Sanchez car...@apache.org: I'm going to be there Friday-Sunday too, let me know On Sat, Dec 27, 2014 at 7:21 PM, Robert Scholte rfscho...@apache.org wrote: Hi all, this week I, Hervé and Karl-Heinz decided to visit fosdem[1] this year to meet each other IRL[2]. The decision was way past the deadline of the CfP, so we can't claim a room to talk with our users. The plan is to meet each other on Sunday, February 1st in Brussels. If there are other developers willing to join, please let us know. thanks, Robert [1] https://fosdem.org/ [2] in real life - 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: [gsoc] Is there a Maven opportunity for Google Summer of Code students?
On Mon, Mar 10, 2014 at 7:06 PM, Jason van Zyl ja...@takari.io wrote: Is there a candidate? Why don't you ask them what they are interested in, if there is one. Or do you have to come up with a project to attract someone? yes, I got in touch with a student interested in GSoC. It's hard for somebody very new to the project to find something that is reasonable to do, and big enough for a summer project. We were looking at the most voted issues in jira and pretty much all of them require a new pom model. On Mar 10, 2014, at 1:49 PM, Carlos Sanchez car...@apache.org wrote: On Mon, Mar 10, 2014 at 2:45 PM, Benson Margulies bimargul...@gmail.com wrote: Realistically, look to plugins more than the core, if you ask me. There's the new not-quite-consumer-pom which might have a subtask. Or pick any of the common plugins and see what's out here. I thought about that, but for GSoC it needs to be something at the ASF, and not Codehaus And is there any new feature big enough to make it as a summer project? would need to be almost a new plugin On Mon, Mar 10, 2014 at 9:42 AM, Carlos Sanchez car...@apache.org wrote: There's a student interesting on doing the GSoC with the Maven project so I was trying to figure out a meaningful project, not to small, not too large, focusing on the top voted issues in jira. But most of them are related to POM and profiles new features/improvements which are not clearly defined/agreed on yet. Anyone has other suggestions? Cheers - 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/takari_io - 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
[gsoc] Is there a Maven opportunity for Google Summer of Code students?
There's a student interesting on doing the GSoC with the Maven project so I was trying to figure out a meaningful project, not to small, not too large, focusing on the top voted issues in jira. But most of them are related to POM and profiles new features/improvements which are not clearly defined/agreed on yet. Anyone has other suggestions? Cheers
Re: [gsoc] Is there a Maven opportunity for Google Summer of Code students?
On Mon, Mar 10, 2014 at 2:45 PM, Benson Margulies bimargul...@gmail.comwrote: Realistically, look to plugins more than the core, if you ask me. There's the new not-quite-consumer-pom which might have a subtask. Or pick any of the common plugins and see what's out here. I thought about that, but for GSoC it needs to be something at the ASF, and not Codehaus And is there any new feature big enough to make it as a summer project? would need to be almost a new plugin On Mon, Mar 10, 2014 at 9:42 AM, Carlos Sanchez car...@apache.org wrote: There's a student interesting on doing the GSoC with the Maven project so I was trying to figure out a meaningful project, not to small, not too large, focusing on the top voted issues in jira. But most of them are related to POM and profiles new features/improvements which are not clearly defined/agreed on yet. Anyone has other suggestions? Cheers - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Houskeeping - Cleanups Branches
no problem to delete mine maven-assembly-plugin-2.0.x On Mon, Feb 10, 2014 at 12:17 AM, Karl Heinz Marbaise khmarba...@gmx.dewrote: Hi, i would like to suggest to remove some branches in the following area: https://svn.apache.org/repos/asf/maven/plugins/branches I would like to delete the following branches, cause they are really old: MASSEMBLY-128/ MASSEMBLY-14/ maven-assembly-plugin-2.0.x/ maven-assembly-plugin-2.2-beta-4/ maven-assembly-plugin-brian-asfrelease/ maven-assembly-plugin-pre2.1-with-installer-support/ maven-assembly-plugin-refactor/ List branch name Revision Author Date etc. MASSEMBLY-128 r428411 | jdcasey | 2006-08-03 16:16:36 +0200 (Thu, 03 Aug 2006) | 2 lines MASSEMBLY-14 r399542 | jdcasey | 2006-05-04 06:36:02 +0200 (Thu, 04 May 2006) | 1 line maven-assembly-plugin-2.0.x r372374 | carlos | 2006-01-26 01:10:55 +0100 (Thu, 26 Jan 2006) | 1 line maven-assembly-plugin-2.2-beta-4 r780691 | jdcasey | 2009-06-01 17:38:58 +0200 (Mon, 01 Jun 2009) | 1 line maven-assembly-plugin-brian-asfrelease r773749 | brianf | 2009-05-12 03:04:56 +0200 (Tue, 12 May 2009) | 1 line maven-assembly-plugin-pre2.1-with-installer-support r399069 | jdcasey | 2006-05-03 00:26:45 +0200 (Wed, 03 May 2006) | 4 lines maven-assembly-plugin-refactor r399761 | jdcasey | 2006-05-04 18:57:20 +0200 (Thu, 04 May 2006) | 2 lines Based on the changed dates these branches are really old Any objections to delete them ? Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Dependency Plugin version 2.4
Hi, The vote has passed with the following result : +1 (binding): Carlos Sanchez, Olivier Lamy, Stephen Connolly +1 (non binding): Tony Chemit I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Dependency Plugin 2.4 Released
The Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.4 Provides utility goals to work with dependencies like copying, unpacking, analyzing, resolving and many more. http://maven.apache.org/plugins/maven-dependency-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.4/version /plugin Release Notes - Maven Dependency Plugin - Version 2.4 Bug * [MDEP-324] Use fixed 2.0.1 plexus-io to work with java7 * [MDEP-306] Unpack does not handle space in includes * [MDEP-299] dependency:get -DrepositoryUrl is mentioned wrong in help Improvement * [MDEP-333] Allow setting the repository id and layout for multiple repositories * [MDEP-304] Make repositoryUrl optional for dependency:get New Feature * [MDEP-334] Add a destination parameter to the get mojo * [MDEP-331] Add to purge-local-repository goal ability to clean only snapshots Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release dependency plugin 2.4
Yep, intended to catch up, seems we have the required votes and will continue the release On Fri, Dec 2, 2011 at 9:39 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 11/15/2011 12:41 AM, Carlos Sanchez wrote: Vote open for 72H. What happened to this vote? Never finalized, and 2.4 is still unreleased? - 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
[VOTE] Release dependency plugin 2.4
Hello, I'd like to release Apache Maven Dependency Plugin 2.4. We fixed 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11214version=17468 Staging repository: https://repository.apache.org/content/repositories/maven-183/ Staging site: http://maven.apache.org/plugins/maven-deploy-plugin-2.4 Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72H. Here my +1 Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] release maven-antrun-plugin version 1.7
+1 On Mon, Oct 31, 2011 at 8:58 AM, Olivier Lamy ol...@apache.org wrote: +1 2011/10/29 Benson Margulies bimargul...@gmail.com: To: Maven Developers List dev@maven.apache.org Subject: [VOTE] Release Maven XXX Plugin version Y.Z Hi, We solved 9 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125version=16808 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MANTRUN+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-120/ Staging site: http://maven.apache.org/plugins/maven-antrun-plugin-1.7/ 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 -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
User management for EC2
I have created a new user for EC2 for my guinea pig chuable ;) using Amazon IAM, a new tool that they created for user management and policies. So we can progressively roll out password sharing. There's a dev group where we can have all users created and they'll have read only permissions https://sites.google.com/a/maestrodev.com/internal-documentation/maestro-3-development/aws
Re: manifest archive issue
you should ask in us...@maven.apache.org Please don't cross-post try something like explained in http://maven.apache.org/shared/maven-archiver/examples/manifest.html On Mon, Jan 31, 2011 at 6:44 AM, sanju ssa...@yahoo.com wrote: Any help regarding this ? Also what is the best way to add released artifact version to zip file ( from POM file) ? -Sanju --- On Fri, 1/28/11, sanju ssa...@yahoo.com wrote: From: sanju ssa...@yahoo.com Subject: manifest archive issue To: iss...@maven.apache.org Date: Friday, January 28, 2011, 3:24 PM I am trying to add archive configuration but that is not helping ( it is not adding/updating manifest file generated as part of the war). archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest /archive Can anyone suggest what could be wrong here ? -Sanju - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Tue, Jan 25, 2011 at 10:28 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 25, 2011 at 11:39 AM, Jason van Zyl ja...@maven.org wrote: When some guy who done virtually nothing for two years vetoes someone [else] then it's not a meritocracy, it's ridiculous is what it is. That was out of line. There is no contribution threshold before you are allowed to have an opinion. We are all concerned about this community and should feel comfortable speaking out if we think something isn't right. I've been on the receiving end of the same thing in the past and it has definitely affected my participation here. I don't want that to happen to anyone else. I have to agree and I support Ralph's veto, there's an issue being discussed on the PMC that needs to be resolved and ignoring it and continue with these changes won't help move forward. -- Wendy - 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
+1 tested in some projects and works fine Are we doing a PR with the press team? On Wed, Oct 6, 2010 at 11:35 AM, Mark Derricutt m...@talios.com wrote: +1 Bring on the 3.0! -- Pull me down under... On Wed, Oct 6, 2010 at 6:32 PM, Brett Porter br...@apache.org wrote: +1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven2 mirror @ netcologne
Hi Christian, Thanks for providing the repo! Please subscribe to repo-maintain...@maven.apache.org, that's the list for repository matters. The mirrors are updated once a day, so you can reduce the frequency of your sync. Cheers On Fri, Jan 1, 2010 at 2:51 AM, Christian Rohmann crohm...@netcologne.de wrote: Hello again, I wrote you in march (see attached email) aber setting up a maven2 mirror in Germany. Unfortunately I never heard back from you. The official repo is rather slow when accessed from Germany (due to small many files and latency I guess), maybe we could help out with our mirror here. If you are interested in the offer, please feel free to list us with the other official mirrors. Happy New Year and Regards from Germany, -- Christian Rohmann Content Delivery Server u. Dienste Network Engineering Design NETCOLOGNE Gesellschaft für Telekommunikation mbH Am Coloneum 9 | 50829 Köln Tel: 0221 -5751 | Fax: 0221 -75751 http://www.netcologne.de Geschäftsführer: Werner Hanf Dipl.-Ing. Karl-Heinz Zankel HRB 25580, AG Köln -- Forwarded message -- From: Mirror-Service mirror-serv...@netcologne.de To: ...@maven.apache.org Date: Thu, 05 Mar 2009 09:10:56 +0100 Subject: Maven2 mirror @ netcologne Hello Maven Dev-Team, we would love to setup a mirror of the maven2 repository in Germany. As there are currently no mirrors in Germany at all, and only two danish mirrors in europe. The NetCologne GmbH is a local ISP in the greater Cologne area. Our machine mirror.netcologne.de currently runs on this hardware: 2x 3Ghz Intel Xeon CPU 2 GB RAM (to be upgraded to 4GB) 3 TB of mirror storage total The machine currently already mirrors a few linux distros (mainly debian) and other free software projects. Regarding internet connectivity, the machine itself has 2 Gigabit/s uplink. Our backbone is then connected to all major peering points in europe (DECIX, AMSIX, LINX) with 20 Gbit/s each. We are also peering in the US (2x EQUINIX) and maintain quite a few private peering with other ISPs including Deutsche Telekom (DTAG) and the DFN (Deutsches Forschungsnetz, the German university network). IPv6 connectivity is coming very soon, so mark that as checked. We configured the rsync to sync with: mirrors.ibiblio.org::maven2 every two hours in the 42nd minute. Please let me know if that's ok, or if we need to adjust that. The repo is already available on [rsync|ftp|http]://mirror.netcologne.de/maven2 If you need to contact me, just mail to crohm...@netcologne.de, as official contact for the mirror use mirror-serv...@netcologne.de. -- Mit freundlichen Grüßen Christian Rohmann --- Network Engineering and Design Tel.: +49 221 -5751 Fax.: +49 221 -75751 NetCologne Gesellschaft für Telekommunikation mbH Am Coloneum 9 50829 Köln Geschäftsführer: Werner Hanf, Karl- Heinz Zankel, Dipl. Ing. HRB 25580, AG Köln www.netcologne.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven2 deploy repository for Apache projects
you should get all that configuration by extending the apache parent pom http://repo1.maven.org/maven2/org/apache/apache/6/apache-6.pom The mailing list for the apache repositroy is reposit...@apache.org On Thu, Sep 3, 2009 at 10:52 AM, Kristian Waagankrist...@apache.org wrote: Hello, The Derby community is moving from Maven1 to Maven2 artifacts. Can anyone tell me what the correct deploy repository to use is? I think it is scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository, and I believe deployed artifacts will make their way out into the world because of the rsync process being run. I did find this FAQ: http://apache.org/dev/repository-faq.html Thanks, -- Kristian - 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: Adding a Looking for Code Quality Managers section into the Maven web site ?
+1 for me too On Wed, Sep 2, 2009 at 11:26 PM, Olivier Lamyol...@apache.org wrote: +1 for me. Provide the patch and it will be a pleasure to commit this. Thanks, -- Olivier 2009/9/2 Freddy Mallet freddy.mal...@gmail.com: Hi all, This proposal is submitted by Romain Pelisse, leader of XRadar Khosuke Kawaguchi, leader of a well known CI server David Vincente, leader of the Maven Dashboard plugin and myself, co-leader of Sonar The idea is simply to add a new Looking for Code Quality Managers section into the right sidebar of the Maven web site homepage bellow Looking for Repository Managers and Looking for CI Servers. This section would contain a short text Take a look at the Code Quality Management platforms available from the community. Clicking on Take a look would display a list of tools with XRadar, Sonar, Maven Dashboard and Hudson (as it contains on the shelf quality reports). It has never been so easy with those tools to monitor source code's health and beginning to combine metrics. Good part of software development departments, which are using Maven, are progressively adopting such quality platforms. We think the Maven ecosystem would be reinforced if it welcomed those quality platforms which are highly based and fully integrated with Maven. Any feedback, bad or good, is welcome. Thanks Romain, Khosuke, David and Freddy -- Olivier - 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: Depending on Artifacts not in central
Benjamin is right, if you rebuild something it should be under your groupId On Wed, Jul 8, 2009 at 1:13 PM, Benjamin Bentmannbenjamin.bentm...@udo.edu wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. 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: Depending on Artifacts not in central
if they rebuild it then it must have something different and they would need to handle the differences in some way. I can't imagine they rebuild the jars just for the sake of doing it. On Wed, Jul 8, 2009 at 1:18 PM, Arnaud HERITIERaherit...@gmail.com wrote: But it creates many issues to resolve transitive dependencies. With that you can have in a tree org.jboss.log4j:log4j:1.2.36 and log4j:log4j:1.2.12Is it working fine if in the pom of org.jboss.log4j:log4j:1.2.36 we set a relocation ? Can it have some others impacts ? Arnaud On Wed, Jul 8, 2009 at 10:13 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. 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: Depending on Artifacts not in central
see MNG-2316 about handling this issue, it has been there for a long time but talking about the repository it is impossible for jboss to publish their builds under the log4j group On Wed, Jul 8, 2009 at 1:43 PM, Stephen Connollystephen.alan.conno...@gmail.com wrote: Hmmm, how would this work w.r.t. resolving... If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, then I would get both artifacts on my classpath with a warning from Maven. If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a transitive via another dependency, then I get both artitfacts and Maven would print a warning If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a transitive via another dependency, then I get only org.jboss.thirdparty:log4j as the transitive dependency has already been provided by a nearer dependency 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: other possible names for the scope could be encapsulated, or bundled 2009/7/8 Stephen Connolly stephen.alan.conno...@gmail.com: we really need some sort of provides groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version /provides another option would be to add a new scope, e.g. implemented dependency groupIdlog4jgroupId artifactIdlog4j/artifactId version[1.2.5,1.3)/version scopeimplemented/scope /dependency that way we can filter out any artifacts which are implemented from the tree... e.g. if I depend on org.jboss.thirdparty:log4j Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that it does not need to be pulled in via transative dependencies 2009/7/8 Daniel Kulp dk...@apache.org: On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: Paul Gier wrote: One issue that will need to be resolved before we can sync, is how to handle our rebuilt thirdparty jars. For example, if a jboss project needs to patch some thirdparty jar, rebuild it, and upload it to our repository AFAIK, somebody building a patched third-party artifact is supposed to not deploy this derived artifact with its original group id but with the group id of the patch creator. So if JBoss creates a patched version of say log4j, it would need to get deployed with org.jboss:log4j or similar. This should be allowed to get synced into central as it can be distinguished from the original log4j:log4j artifact of the project owner. Except there THEN becomes the issue if someone depends on the normal log4j artifact as well as some JBoss artifact that then transitively pulls in org.jboss:log4j, they end up with two versions of log4j on the classpath with all kinds of non-fun things happening. Dan Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - 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: [jira] Closed: (MAVENUPLOAD-2464) Please upload Clojure 1.0.0
you have to send emails to dev-unsubscribe-durga.tirunagari=sun@maven.apache.org issues-unsubscribe-durga.tirunagari=sun@maven.apache.org ...and so on for the lists you are subscribed to On Wed, Jul 8, 2009 at 2:12 PM, Durga Deep Tirunagaridurga.tirunag...@sun.com wrote: can one of the people listed in here ( with no clickable e-mail address ). Remove me from this user list ? E-mail (durga.tirunag...@sun.com ) http://jira.codehaus.org/secure/Administrators.jspa System Administrators Here is the list of system administrators for this installation of JIRA. System Administrators have complete administrative rights including permission to manage underlying JIRA system configuration such as backups and services. * Alan Cabrera * Andrew Eisenberg * Arnaud Heritier * Ben Walding * bob mcwhirter * Brett Porter * Brian Topping * Bruce Snyder * Contegix Support * Dain Sundstrom * Dan Diephouse * Dan North * David Blevins * Dennis Lundberg * Edward Povazan * Emmanuel Venisse * Eugene Kuleshov * Guillaume Laforge * Jacques Morel * James E. Ervin * James Macgill * Jason Dillon * Jason van Zyl * Jody Garnett * Paul Hammant * Peter Donald * peter royal * Rodrigo B. de Oliveira * Scott Farquhar * Trygve Laugstol * Vincent Massol * Werner Guttmann * Xircles System User Thanks a bunch On Jul 8, 2009, at 1:26 PM, Carlos Sanchez (JIRA) wrote: [ http://jira.codehaus.org/browse/MAVENUPLOAD-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2464. --- Assignee: Carlos Sanchez Resolution: Fixed Please upload Clojure 1.0.0 --- Key: MAVENUPLOAD-2464 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2464 Project: Maven Upload Requests Issue Type: Wish Reporter: Stefan Hübner Assignee: Carlos Sanchez Please upload Clojure 1.0.0 to Maven Central. The bundle contains the following files: - pom.xml - clojure-1.0.0.jar - clojure-1.0.0-slim.jar (variant of clojure-1.0.0.jar without precompiled Lisp sources) - clojure-1.0.0-sources.jar The Clojure project lives at http://clojure.org which is owned by Clojure's creator Rich Hickey (see http://whois.domaintools.com/clojure.org). I'm submitting this bundle on behalf of the Clojure community (see this thread: http://groups.google.com/group/clojure/browse_thread/thread/fd538f118613cbbf). Thank you, Stefan Hübner -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Bouncy Castle Jars
You'd have to go through the Maven repository upload process described in http://maven.apache.org/guides/mini/guide-central-repository-upload.html On Sat, Jun 6, 2009 at 5:17 PM, Tim Pizeyt...@paneris.org wrote: Hi, I have asked the Bouncy Castle guys if they will push to a Maven Repository and they replied that they publish only to http://www.bouncycastle.org/latest_releases.html So could someone at the Maven end ensure that all those jars are synched with? thanks Tim -- We are in dialogue. - 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 Meetup In Amsterdam?
Hi Arje, seems there's some interested people in a Maven Meetup, how can we proceed? can we get the wiki created for people to signup and see how many we are? Thanks On Thu, Mar 5, 2009 at 1:28 AM, Gabriele Columbro g.colum...@sourcesense.com wrote: I'd reallly believe that a Maven Meetup in Amsterdam is a very good idea and a very nice place to share our Maven knowledge, too many times felt by junior developers as highly black magic ;) And for us (Sourcesense) to discuss some of our work in Sourcesense around Maven ALM support [1] and around Alfresco ECM Maven support [2]. Any other maven user/dev interested to join (I'm extending the request to the user list to get some more attendees)? I believe that getting to 15/20~ attendees is to be considered the treshold for organizing this. I will be also forwarding this email to my customers to get more attention around the topic. HTH, Gab [1] http://code.google.com/p/maven-calm [2] http://code.google.com/p/maven-alfresco-archetypes 2009/2/27 Rogier Peters rogier.pet...@gmail.com Hi Petar, Great idea. We're a couple (3-5) developers from Sourcesense NL, based in Amsterdam. We would be interested in coming, and also giving a short talk on Application Lifecycle Management with Maven. Since we're based in Amsterdam, we could also help organizing or drum up some more local developers. @nick you're probably there, more people from IProfs interested? Regards, Rogier On Wed, Feb 18, 2009 at 8:35 PM, Petar Tahchiev paranoia...@gmail.comwrote: Hi guys, I got an email from Arje Cahn with a proposal to make a Maven GetTogether/Meetup during the ApacheCON in Amsterdam. I am very interested in such an event but I do feel that it will only make sense if more of the Maven developers are present at the conference. I know for sure me, Carlos and Wendy are going to be there. Anybody else planning to attend? If we get there more people we can easily setup a wiki page and announce a few sessions there. What do you think? Here is the email from Arje: == Hi all, I'm sending you this email because we've done GetTogethers / Meetups together, or have spoken about them somewhere in the past. If you feel I should be addressing different people, or different projects, I'd be grateful if you could point me to the right project and/or person! :) As you are probably very much aware of, the ApacheCon Europe is in about 7 weeks, in Amsterdam. I got a really nice offer from the ApacheCon producers. The Matterhorn rooms are available in the evenings for Meetup / GetTogether style events. This means we can host up to 3 evening Meetups, from 18:00 - 22:00, with our own program, on Monday evening and Tuesday evening, all within the ApacheCon venue (the Movenpick). Meetups happen after the trainings. This is in my opinion a much better opportunity than we had last year where we were 1) in a different location 2) conflicting with the hackaton 3) conflicting with trainings Grant, I'd love to hear your thoughts from your Lucene perspective. I know last year was unclear and I hope to be able to straighten that out with you this year. We're *not* organizing Lucene meetups without having Lucene people on board :) Potentially, we could have 6 Meetups in total. The rooms can hold up to 100 people each. Wifi, beamers, etc, is all taken care of. The question I have for you all, is whether you think you and / or your project would be interested in filling an evening. Can you organize between 20 and 100 people from your project, and put up an agenda with speakers and talks? Also, we'll have to come up with some sponsors. To give you an idea - last years Meetups were sponsored by 2 to 4 sponsors per project, paying roughly 1000 euro each to cover all costs. These sponsors will then become official ApacheCon Meetup sponsors and get marketed like that on the ApacheCon website. Right now, the planners have asked me to come up with a list of Apache projects that would be interested in the idea. If you're interested, please let me know ASAP, as I need to follow up on Monday to be able to be in time with all the marketing stuff going on around ApacheCon. Hope you like this idea as much as I do! -- Kind regards, Arjé Cahn -- Regards, Petar! Karlovo, Bulgaria. - - - - - - - - | Author @ Manning Publications. | Senior Solution Architect @ Unic | BGJUG-Bulgarian Java User Group Leader. | Apache Maven Developer. | Apache Jakarta PMC member. | Jakarta Cactus Lead Developer. | Codehaus Plexus Developer | Blogger: http://weblogs.java.net/blog/paranoiabla/ - - - - - - - - Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 -- Rogier Peters rog...@twitter, flickr, delicious -- Gabriele Columbro Alfresco ECM Product Strategy Consultant +31 627 565 103
Re: Where did NMaven go?
NPanday is based on 0.14 and also actively developed at http://www.codeplex.com/npanday On Thu, Mar 5, 2009 at 2:59 PM, James William Dumay ja...@atlassian.com wrote: NMaven has moved to http://www.codeplex.com/nmaven/ Thanks James On 06/03/2009, at 9:04 AM, Dennis Lundberg wrote: Hi We're trying to find the best version of NMaven to start to use at work. I didn't follow the discussions at the time, but it clear to me that NMaven didn't graduate from incubation. According to this page: http://incubator.apache.org/nmaven/ there seems to be three different alternatives. Can someone shed some light on which ones are alive and kicking? -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Meetup In Amsterdam?
ok, added to the wiki and created our own page at http://docs.codehaus.org/display/MAVENUSER/Maven+Meetup+ApacheCON+Europe+2009 please add yourself to the list if you plan to attend On Thu, Mar 5, 2009 at 12:51 PM, Arje Cahn a.c...@onehippo.com wrote: Hi guys, seems there's some interested people in a Maven Meetup, how can we proceed? can we get the wiki created for people to signup and see how many we are? Sure, go ahead! Just setup a page like Wicket, Jackrabbit, Lucene and Portals did and add a link to http://wiki.apache.org/apachecon/ApacheMeetupsEu09 I'll be sending out an email to the Dutch Java User group mailinglist this weekend, so if you have anything you'd like me to put in there please send it to me today or tomorrow morning. See you in Amsterdam! - Arjé Cahn Hippo a.c...@onehippo.com / a...@apache.org Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-5100 +1 (707) 773-4646 www.onehippo.com i...@onehippo.com - Get Hippo CMS 7 at http://www.onehippo.org My blog: http://blogs.hippo.nl/arje - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Meetup In Amsterdam?
Maria (Deng) is going to be there too It'd be a good idea. On Wed, Feb 18, 2009 at 11:35 AM, Petar Tahchiev paranoia...@gmail.com wrote: Hi guys, I got an email from Arje Cahn with a proposal to make a Maven GetTogether/Meetup during the ApacheCON in Amsterdam. I am very interested in such an event but I do feel that it will only make sense if more of the Maven developers are present at the conference. I know for sure me, Carlos and Wendy are going to be there. Anybody else planning to attend? If we get there more people we can easily setup a wiki page and announce a few sessions there. What do you think? Here is the email from Arje: == Hi all, I'm sending you this email because we've done GetTogethers / Meetups together, or have spoken about them somewhere in the past. If you feel I should be addressing different people, or different projects, I'd be grateful if you could point me to the right project and/or person! :) As you are probably very much aware of, the ApacheCon Europe is in about 7 weeks, in Amsterdam. I got a really nice offer from the ApacheCon producers. The Matterhorn rooms are available in the evenings for Meetup / GetTogether style events. This means we can host up to 3 evening Meetups, from 18:00 - 22:00, with our own program, on Monday evening and Tuesday evening, all within the ApacheCon venue (the Movenpick). Meetups happen after the trainings. This is in my opinion a much better opportunity than we had last year where we were 1) in a different location 2) conflicting with the hackaton 3) conflicting with trainings Grant, I'd love to hear your thoughts from your Lucene perspective. I know last year was unclear and I hope to be able to straighten that out with you this year. We're *not* organizing Lucene meetups without having Lucene people on board :) Potentially, we could have 6 Meetups in total. The rooms can hold up to 100 people each. Wifi, beamers, etc, is all taken care of. The question I have for you all, is whether you think you and / or your project would be interested in filling an evening. Can you organize between 20 and 100 people from your project, and put up an agenda with speakers and talks? Also, we'll have to come up with some sponsors. To give you an idea - last years Meetups were sponsored by 2 to 4 sponsors per project, paying roughly 1000 euro each to cover all costs. These sponsors will then become official ApacheCon Meetup sponsors and get marketed like that on the ApacheCon website. Right now, the planners have asked me to come up with a list of Apache projects that would be interested in the idea. If you're interested, please let me know ASAP, as I need to follow up on Monday to be able to be in time with all the marketing stuff going on around ApacheCon. Hope you like this idea as much as I do! -- Kind regards, Arjé Cahn -- Regards, Petar! Karlovo, Bulgaria. - - - - - - - - | Author @ Manning Publications. | Senior Solution Architect @ Unic | BGJUG-Bulgarian Java User Group Leader. | Apache Maven Developer. | Apache Jakarta PMC member. | Jakarta Cactus Lead Developer. | Codehaus Plexus Developer | Blogger: http://weblogs.java.net/blog/paranoiabla/ - - - - - - - - Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r737976 - in /maven/repository-tools/trunk/src/bin: crontab.txt synchronize-inbound.sh
I changed the crontab, the sync was not having place cd $HOME/bin/synchronize/synchronize-inbound On Mon, Jan 26, 2009 at 6:25 PM, bri...@apache.org wrote: Author: brianf Date: Tue Jan 27 02:25:34 2009 New Revision: 737976 URL: http://svn.apache.org/viewvc?rev=737976view=rev Log: pull inbound sync into a separate script Added: maven/repository-tools/trunk/src/bin/synchronize-inbound.sh Modified: maven/repository-tools/trunk/src/bin/crontab.txt Modified: maven/repository-tools/trunk/src/bin/crontab.txt URL: http://svn.apache.org/viewvc/maven/repository-tools/trunk/src/bin/crontab.txt?rev=737976r1=737975r2=737976view=diff == --- maven/repository-tools/trunk/src/bin/crontab.txt (original) +++ maven/repository-tools/trunk/src/bin/crontab.txt Tue Jan 27 02:25:34 2009 @@ -7,7 +7,7 @@ # sync rewrite rules to m1 repo at ibiblio 51 19 * * * cd $HOME/bin; ./synchronize-rewrite-rules-to-ibiblio.sh $HOME/bin/synchronize.properties # sync m2 repos -16 17 * * * cd $HOME/bin/synchronize/m2-sync; svn up sync.csv; /opt/java/sdk/current/bin/java -jar maven-meeper-1-SNAPSHOT-jar-with-dependencies.jar sync.properties sync.csv; date /home/maven/repository-staging/to-ibiblio/maven2/last_updated.txt +16 17 * * * cd $HOME/bin/synchronize/synchronize-inbound # sync central to cica.es mirror 30 21 * * * cd $HOME/bin; ./synchronize-central-to-cica.sh $HOME/bin/synchronize.properties # sync central to repo.exist.com mirror Added: maven/repository-tools/trunk/src/bin/synchronize-inbound.sh URL: http://svn.apache.org/viewvc/maven/repository-tools/trunk/src/bin/synchronize-inbound.sh?rev=737976view=auto == --- maven/repository-tools/trunk/src/bin/synchronize-inbound.sh (added) +++ maven/repository-tools/trunk/src/bin/synchronize-inbound.sh Tue Jan 27 02:25:34 2009 @@ -0,0 +1,5 @@ +#!/bin/sh +cd $HOME/bin/synchronize/m2-sync +svn up sync.csv +/opt/java/sdk/current/bin/java -jar maven-meeper-1-SNAPSHOT-jar-with-dependencies.jar sync.properties sync.csv +date /home/maven/repository-staging/to-ibiblio/maven2/last_updated.txt \ No newline at end of file - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New Mirror
please join the repo-maintain...@maven.apache.org mailing list for important notifications repo-maintainers-subscr...@maven.apache.org btw how are you syncing? rsync from ibiblio? On Mon, Jan 5, 2009 at 5:47 PM, TDS.net Mirrors mirr...@tds.net wrote: Hello Devs, I have setup a new mirror for the maven software. The mirror's location is Madison, WI. I am providing ftp, http, and rsync access for the maven software. It can be accessed via http://maven.mirrors.tds.net/pub/ The server is capped currently at 500Mbit/s. I will sync 2x daily at 7am pm. If you have any other questions, please let me know. Rob - 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] Maven 3.0-alpha-1
+1 On Mon, Jan 5, 2009 at 6:55 PM, Jason van Zyl jvan...@sonatype.com wrote: Put it in JIRA for alpha-2. Either this should come out or we update the version. On 5-Jan-09, at 12:49 PM, Vincent Siveton wrote: +0 Since the model adds new field (ActivationCustom), I think the xsd version should be 4.0.1 or 5.0. Cheers, Vincent 2009/1/4 Jason van Zyl jvan...@sonatype.com: 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 - 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 -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: 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 Day Summary
On Wed, Oct 15, 2008 at 10:38 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Here's a short summary of what we chatted about and did at Maven Day: 1) We helped the folks at Google get a repository setup. Projects like Collections, and GWT. We noticed Nicolas already syncing some Google projects so Greg Kick was going to get into contact with Nicolas. I had sent this to the repo-mantainers list: Is this for google official projects or code.google.com projects? who is going to be deploying to that repository and how? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Day Summary
ok, so i'll redirect any official google project upload request to him On Wed, Oct 15, 2008 at 12:06 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 15-Oct-08, at 11:11 AM, Carlos Sanchez wrote: On Wed, Oct 15, 2008 at 10:38 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, Here's a short summary of what we chatted about and did at Maven Day: 1) We helped the folks at Google get a repository setup. Projects like Collections, and GWT. We noticed Nicolas already syncing some Google projects so Greg Kick was going to get into contact with Nicolas. I had sent this to the repo-mantainers list: Is this for google official projects or code.google.com projects? Yes. who is going to be deploying to that repository and how? Projects that Greg Kick sets up internally at Google. They are using subversion over SSL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven repository
right now only rsync is available for non public repos On Fri, Sep 26, 2008 at 1:42 AM, Assimov, Tair (EXT-Other - FI/Espoo) [EMAIL PROTECTED] wrote: Hello! I hope this is the right email for my question concerning maven mirrors. We have an internal Maven mirror in our organization which does rsync from ibiblio.org, so we would like to ensure there is no threat of MITM attack. Could you please tell how is it possible to mirror from ibiblio or any other official mirrors with https or rsync over ssh, instead of native rsync protocol (http://maven.apache.org/guides/mini/guide-mirror-settings.html)? Thanks in advance, Tair. -- Tair Assimov Software Architect, SCM Solutions T3 Advanced Application Support EE Subversion, NSN IT Eficode Oy Phone: +358 45 638 4028 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]
Releasing clean plugin
Hi, Is there something holding the release of the clean plugin? Last release 2.2 was Nov 2007 and 8 issues have been fixed since then http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128styleName=Htmlversion=13905 I see file-management needs to be released too, last release was also Nov 2007 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing clean plugin
yep, I'm offering help, if not i wouldn't ask :) but Ben has been doing work on it lately, so let's see if there's something missing there On Thu, Sep 25, 2008 at 12:15 PM, Stephen Connolly [EMAIL PROTECTED] wrote: Sounds like you're offering to drive the release! My understanding is that most of these just lack somebody to push them out the door... But what do I know! -Stephen Release early release often Connolly 2008/9/25 Carlos Sanchez [EMAIL PROTECTED] Hi, Is there something holding the release of the clean plugin? Last release 2.2 was Nov 2007 and 8 issues have been fixed since then http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11128styleName=Htmlversion=13905 I see file-management needs to be released too, last release was also Nov 2007 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Topaz OWLAPI artifacts to ibiblio
http://maven.apache.org/guides/mini/guide-central-repository-upload.html On Thu, Aug 21, 2008 at 4:43 PM, Amit Kapoor [EMAIL PROTECTED] wrote: Hi, We have setup our Maven 2 repository at http://maven.topazproject.org/maven2/ for Topaz project (http://www.topazproject.org/). What is the process to sync this with ibiblio? Thanks. Amit - 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]
[ANN] Maven Antrun Plugin 1.2 Released
The Maven team is pleased to announce the release of the Maven Antrun Plugin, version 1.2 This plugin provides the ability to run Ant tasks from within Maven 2. You can even embed your Ant scripts in the POM! http://maven.apache.org/plugins/maven-antrun-plugin/ You can run mvn -up to get the latest version of the plugin, or specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId version1.2/version /plugin Release Notes - Maven 2.x Antrun Plugin - Version 1.2 Bug * [MANTRUN-32] - ant tasks don't use correct environment in antrun plugin * [MANTRUN-38] - Messed up maven.dependency.classpath when using maven-antrun-plugin-1.1 * [MANTRUN-75] - tasks if or unless does not work properly * [MANTRUN-82] - skip test * [MANTRUN-85] - Plublic documentation is out of sync with released plugin Improvement * [MANTRUN-35] - mvn debug level not passed to ant * [MANTRUN-43] - Standard ant properties are missing * [MANTRUN-46] - Move the description of the mojo from @description to the top of the class's comment block New Feature * [MANTRUN-41] - Easy access to dependency jars * [MANTRUN-44] - No way to skip antrun when -Dmaven.test.skip is set Task * [MANTRUN-55] - Review Plugin Documentation http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven antrun plugin version 1.2
Result 3 +1 (including mine) will proceed with the release On Mon, Jul 21, 2008 at 8:53 AM, John Casey [EMAIL PROTECTED] wrote: +1 Carlos Sanchez wrote: Release was rolledback and performed again, site and staging repo updated, please restart the voting process http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 On Wed, Jul 16, 2008 at 1:46 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: the error in clirr would need to be fixed too. I'll try to find some time during the weekend to rollback and post a new release On Wed, Jul 16, 2008 at 1:27 PM, Vincent Siveton [EMAIL PROTECTED] wrote: Thanks Dennis to fix them. BTW Carlos, could you also include a release notes link on the jira report? We discussed about it recently. Cheers, Vincent 2008/7/16, Dennis Lundberg [EMAIL PROTECTED]: Thanks for pushing for this release Carlos! Unfortunately there are a couple of things that needs to be fixed before we can release 1.2, for which I have to vote -1 to the current release candidate. - The POM is missing the license header (I fixed this in svn) - The Source files have the old license headers (I fixed this in svn) - The documentation fix for MANTRUN-75 is not included in the 1.2 tag Here are some minor things that are nice to fix prior to the release, all of which I have fixed in svn trunk. - Use latest version of maven-plugin-plugin and maven-site-plugin - Fix errors reported by Checkstyle - Add missing scm info in the POM The Clirr report [1] shows one error, one of the constructors for AntPropertyHelper has changed the number of parameters. This was done in r374150 as part of the fix for MANTRUN-41. I guess that we can live with that change. Do we need to document it? [1] http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html Carlos Sanchez wrote: Hi, 9 issues fixed. Last release was 2.5 years ago http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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] -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven antrun plugin version 1.2
Release was rolledback and performed again, site and staging repo updated, please restart the voting process http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 On Wed, Jul 16, 2008 at 1:46 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: the error in clirr would need to be fixed too. I'll try to find some time during the weekend to rollback and post a new release On Wed, Jul 16, 2008 at 1:27 PM, Vincent Siveton [EMAIL PROTECTED] wrote: Thanks Dennis to fix them. BTW Carlos, could you also include a release notes link on the jira report? We discussed about it recently. Cheers, Vincent 2008/7/16, Dennis Lundberg [EMAIL PROTECTED]: Thanks for pushing for this release Carlos! Unfortunately there are a couple of things that needs to be fixed before we can release 1.2, for which I have to vote -1 to the current release candidate. - The POM is missing the license header (I fixed this in svn) - The Source files have the old license headers (I fixed this in svn) - The documentation fix for MANTRUN-75 is not included in the 1.2 tag Here are some minor things that are nice to fix prior to the release, all of which I have fixed in svn trunk. - Use latest version of maven-plugin-plugin and maven-site-plugin - Fix errors reported by Checkstyle - Add missing scm info in the POM The Clirr report [1] shows one error, one of the constructors for AntPropertyHelper has changed the number of parameters. This was done in r374150 as part of the fix for MANTRUN-41. I guess that we can live with that change. Do we need to document it? [1] http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html Carlos Sanchez wrote: Hi, 9 issues fixed. Last release was 2.5 years ago http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - 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]
[VOTE] Release Maven antrun plugin version 1.2
Hi, 9 issues fixed. Last release was 2.5 years ago http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to validate a Maven release? Fwd: [VOTE] Release Maven antrun plugin version 1.2
whatever it is needs to be added to http://maven.apache.org/developers/release/releasing.html On Wed, Jul 16, 2008 at 1:35 PM, Vincent Siveton [EMAIL PROTECTED] wrote: Hi guys, What are the minimalist things that we need to check for a good Maven release? Dennis points that we need to reduce Checkstyle errors, checking Clirr report and licenses. Any others ideas? Cheers, Vincent -- Forwarded message -- From: Dennis Lundberg [EMAIL PROTECTED] Date: 16 juil. 2008 15:48 Subject: Re: [VOTE] Release Maven antrun plugin version 1.2 To: Maven Developers List dev@maven.apache.org Thanks for pushing for this release Carlos! Unfortunately there are a couple of things that needs to be fixed before we can release 1.2, for which I have to vote -1 to the current release candidate. - The POM is missing the license header (I fixed this in svn) - The Source files have the old license headers (I fixed this in svn) - The documentation fix for MANTRUN-75 is not included in the 1.2 tag Here are some minor things that are nice to fix prior to the release, all of which I have fixed in svn trunk. - Use latest version of maven-plugin-plugin and maven-site-plugin - Fix errors reported by Checkstyle - Add missing scm info in the POM The Clirr report [1] shows one error, one of the constructors for AntPropertyHelper has changed the number of parameters. This was done in r374150 as part of the fix for MANTRUN-41. I guess that we can live with that change. Do we need to document it? [1] http://maven.apache.org/plugins/maven-antrun-plugin-1.2/clirr-report.html Carlos Sanchez wrote: Hi, 9 issues fixed. Last release was 2.5 years ago http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11125styleName=Htmlversion=12210 Staging repo: http://people.apache.org/~carlos/staging-repo Staging site: http://maven.apache.org/plugins/maven-antrun-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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal: setuid-root fix-permissions.sh
this point was raised several times before, and it was opposed by
infra, so you'd need to ask them. Here I'm sure everybody is +1 ;)
On Tue, May 13, 2008 at 6:31 PM, Dan Fabulich [EMAIL PROTECTED] wrote:
I've rewritten fix-permissions.sh to use absolute paths for find and chmod,
and removed the -user ${USER} check. I believe this modified script
should be safe to be configured setuid root. That way, anybody could run it
and clean up anyone's fix-permissions errors, even if someone else forgot.
I know we've been talking about setting it up as a cron job for months, but
apparently that's politically difficult (I suppose that it could be more
maintenance work). In this proposal, all I want is for somebody to mark
this version of the script setuid root; it's a one-time-only chmod command.
Unlike the cron proposal, I believe this could actually happen this week if
we decided it should happen.
Agreed?
-
echo Checking /www/people.apache.org/repo/m2-snapshot-repository
/usr/bin/find /www/people.apache.org/repo/m2-snapshot-repository ! -perm 775
-type d -exec /bin/chmod 775 {} \; -print
/usr/bin/find /www/people.apache.org/repo/m2-snapshot-repository ! -perm 664
-iname maven-metadata.xml* -exec /bin/chmod 664 {} \; -print
echo Checking /www/people.apache.org/repo/m2-ibiblio-rsync-repository
/usr/bin/find /www/people.apache.org/repo/m2-ibiblio-rsync-repository !
-perm 775 -type d -exec /bin/chmod 775 {} \; -print
/usr/bin/find /www/people.apache.org/repo/m2-ibiblio-rsync-repository !
-perm 664 -iname maven-metadata.xml* -exec /bin/chmod 664 {} \; -print
echo Checking /www/people.apache.org/repo/m2-incubating-repository
/usr/bin/find /www/people.apache.org/repo/m2-incubating-repository ! -perm
775 -type d -exec /bin/chmod 775 {} \; -print
/usr/bin/find /www/people.apache.org/repo/m2-incubating-repository ! -perm
664 -iname maven-metadata.xml* -exec /bin/chmod 664 {} \; -print
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven core : Plexus vs Spring / OSGi ?
I'd really love to see that, but that's not news at all ;) On Fri, May 2, 2008 at 5:53 AM, nicolas de loof [EMAIL PROTECTED] wrote: [ ] Note to plexus lovers : CONTROVERSAL PROPOSAL, please don't blame me and just give good arguments ! [ ] Maven is built on Plexus. This lightweight container is used (afaik) for : - simple (javadoc) annotation-based programming model - lifecycle management - dependency injection - classloader isolation for plugins (using classworld) Let's now consider the today responses to the same requirements : - Since Java5, annotations are common, and JSR-250 introduces standard annotations that can address some basic lifecycle and IoC requirements. - The IoC container ecosystem is dominated by Springframework. Maybe not the best technical one for any reason, but the best documented and most know by developers. - Classloader isolation is very well adressed by OSGi, with the advantage of beeing a recognized standard, with many documentation AND business interest. Maybe Plexus was a very advanced container when it was created, but it did not become the today 1rst choice technology. Considering an opensource tool like maven is built by volunteers developers, it would be a good thing to attract talentuous ones to use up-to-date and well known technologies. As an example, Archiva (trunk) is migrating to Spring as it's IoC container. Could we consider for future maven version (let's say 2.2, or 3.0 - as 2.1 is allready in advanced development phase) to replace plexus with a combination of Java5 + Spring + OSGi ? Nicolas. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use central repo into an Eclipse project?
On Tue, Apr 15, 2008 at 4:06 AM, Vincent Siveton [EMAIL PROTECTED] wrote: Hi Carlos, 2008/4/14, Carlos Sanchez [EMAIL PROTECTED]: btw the problem is not just let's make the repo work for maven as there are other consumers out there, ie. Equinox provisioning, that may like to use the repo as a source and if you change their metadata to adjust it to maven it wont be useful for them anymore Agree and it is why I did MNG-3518, ie only changing Maven logic. agree, Maven should keep the old behavior for snapshot timestamps but should change for the rest But, WDYT to put Eclipse artifacts without classifier in central? Make sense for osgi/eclipse? i think it'd be confusing because there are many builds and the only difference would be where the build is bundled. ie it could happen that eclipse 4.0 bundles foo-1.0.0.20080101 but then foo could release a new build foo-1.0.0.20080201 at least theoretically it could happen but as I'm not going to invest much time on this I'm leaving the door open for other people that are actually willing to do the work to come up with usable solutions Cheers, Vincent On Mon, Apr 14, 2008 at 10:44 AM, Carlos Sanchez [EMAIL PROTECTED] wrote: i gave a talk at eclipsecon covering the subject. You'll need to use maven 2.0.9+ and force the versions in dependencyManagement You can find the slides at http://www.jroller.com/carlossg/entry/slides_from_eclipsecon On Mon, Apr 14, 2008 at 7:05 AM, Micah Hainline [EMAIL PROTECTED] wrote: Hey Vincent, the qualifiers in the release versions of the Eclipse plugins are better off stripped out of the repositories in my opinion. Every release version of the Eclipse platform should have the incremental version number incremented, so if the community was going to make another release of the 3.2 branch it would be 3.2.3--they wouldn't rely on the qualifier for that. I guess what I'm saying is the qualifier doesn't have much useful information for the release versions, so it makes sense to me to strip the qualifier when you're adding the Eclipse artifacts to your repository. eclipse:make-artifacts[1] does this by default. If you were to need to build against the nightly Eclipse build or something of that nature you would have to do something different, but my sense is that you are not. These are just my opinions on the subject, and I'd be interested to hear any others. This was just what I found easiest to deal with. [1] http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html - Original Message - From: Vincent Siveton [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Monday, April 14, 2008 5:52:35 AM (GMT-0600) America/Chicago Subject: How to use central repo into an Eclipse project? Hi, Background: Trying to mavenize an Eclipse Plugin project, I got error messages like the following: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) I put in jira a test project to reproduce this error [1]. Discussions: After some investigations: * the error comes from transitive dependencies (BTW I updated DefaultArtifactCollector (r647445) to have the dependency trail). * a version without qualifier is newer than a version with qualifier, i.e in our case 1.0.0 is newer than 1.0.0-v20070606 (see also [2] [3]). This logic is valid for alpha, beta (i.e. 1.0-alpha-1 1.0) but not for Eclipse artifacts. * Carlos in [4] suggested to use exclusions or dependencyManagement. With this approach, POM will quickly become ugly (see for instance ASF Directory Studio POM [6]). Moreover, the actual repo is just unusable because transitive dependencies are not resolved at all due to the current logic. * Using eclipse:to-maven doesn't help [5] So, how to make the Eclipse repo workable for an Eclipse project? A solution could be done in [1], but this might be Eclipse specific. At least, the repo will work :) Thoughts? Vincent [1] http://jira.codehaus.org/browse/MNG-3518 [2] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges [3] http://docs.codehaus.org/display/MAVEN/Versioning [4] http://www.nabble.com/Re%3A-in-repo1-it-is-available-td13950144s177.html#a14708458 [5] http://www.nabble.com/Couldn%27t-find-a-version-when-building-pde-maven-plugin-td16116114s177.html [6] http://svn.apache.org/repos/asf/directory/studio/trunk/pom.xml
Re: How to use central repo into an Eclipse project?
i gave a talk at eclipsecon covering the subject. You'll need to use maven 2.0.9+ and force the versions in dependencyManagement You can find the slides at http://www.jroller.com/carlossg/entry/slides_from_eclipsecon On Mon, Apr 14, 2008 at 7:05 AM, Micah Hainline [EMAIL PROTECTED] wrote: Hey Vincent, the qualifiers in the release versions of the Eclipse plugins are better off stripped out of the repositories in my opinion. Every release version of the Eclipse platform should have the incremental version number incremented, so if the community was going to make another release of the 3.2 branch it would be 3.2.3--they wouldn't rely on the qualifier for that. I guess what I'm saying is the qualifier doesn't have much useful information for the release versions, so it makes sense to me to strip the qualifier when you're adding the Eclipse artifacts to your repository. eclipse:make-artifacts[1] does this by default. If you were to need to build against the nightly Eclipse build or something of that nature you would have to do something different, but my sense is that you are not. These are just my opinions on the subject, and I'd be interested to hear any others. This was just what I found easiest to deal with. [1] http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html - Original Message - From: Vincent Siveton [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Monday, April 14, 2008 5:52:35 AM (GMT-0600) America/Chicago Subject: How to use central repo into an Eclipse project? Hi, Background: Trying to mavenize an Eclipse Plugin project, I got error messages like the following: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) I put in jira a test project to reproduce this error [1]. Discussions: After some investigations: * the error comes from transitive dependencies (BTW I updated DefaultArtifactCollector (r647445) to have the dependency trail). * a version without qualifier is newer than a version with qualifier, i.e in our case 1.0.0 is newer than 1.0.0-v20070606 (see also [2] [3]). This logic is valid for alpha, beta (i.e. 1.0-alpha-1 1.0) but not for Eclipse artifacts. * Carlos in [4] suggested to use exclusions or dependencyManagement. With this approach, POM will quickly become ugly (see for instance ASF Directory Studio POM [6]). Moreover, the actual repo is just unusable because transitive dependencies are not resolved at all due to the current logic. * Using eclipse:to-maven doesn't help [5] So, how to make the Eclipse repo workable for an Eclipse project? A solution could be done in [1], but this might be Eclipse specific. At least, the repo will work :) Thoughts? Vincent [1] http://jira.codehaus.org/browse/MNG-3518 [2] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges [3] http://docs.codehaus.org/display/MAVEN/Versioning [4] http://www.nabble.com/Re%3A-in-repo1-it-is-available-td13950144s177.html#a14708458 [5] http://www.nabble.com/Couldn%27t-find-a-version-when-building-pde-maven-plugin-td16116114s177.html [6] http://svn.apache.org/repos/asf/directory/studio/trunk/pom.xml - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use central repo into an Eclipse project?
btw the problem is not just let's make the repo work for maven as there are other consumers out there, ie. Equinox provisioning, that may like to use the repo as a source and if you change their metadata to adjust it to maven it wont be useful for them anymore On Mon, Apr 14, 2008 at 10:44 AM, Carlos Sanchez [EMAIL PROTECTED] wrote: i gave a talk at eclipsecon covering the subject. You'll need to use maven 2.0.9+ and force the versions in dependencyManagement You can find the slides at http://www.jroller.com/carlossg/entry/slides_from_eclipsecon On Mon, Apr 14, 2008 at 7:05 AM, Micah Hainline [EMAIL PROTECTED] wrote: Hey Vincent, the qualifiers in the release versions of the Eclipse plugins are better off stripped out of the repositories in my opinion. Every release version of the Eclipse platform should have the incremental version number incremented, so if the community was going to make another release of the 3.2 branch it would be 3.2.3--they wouldn't rely on the qualifier for that. I guess what I'm saying is the qualifier doesn't have much useful information for the release versions, so it makes sense to me to strip the qualifier when you're adding the Eclipse artifacts to your repository. eclipse:make-artifacts[1] does this by default. If you were to need to build against the nightly Eclipse build or something of that nature you would have to do something different, but my sense is that you are not. These are just my opinions on the subject, and I'd be interested to hear any others. This was just what I found easiest to deal with. [1] http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html - Original Message - From: Vincent Siveton [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Monday, April 14, 2008 5:52:35 AM (GMT-0600) America/Chicago Subject: How to use central repo into an Eclipse project? Hi, Background: Trying to mavenize an Eclipse Plugin project, I got error messages like the following: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) I put in jira a test project to reproduce this error [1]. Discussions: After some investigations: * the error comes from transitive dependencies (BTW I updated DefaultArtifactCollector (r647445) to have the dependency trail). * a version without qualifier is newer than a version with qualifier, i.e in our case 1.0.0 is newer than 1.0.0-v20070606 (see also [2] [3]). This logic is valid for alpha, beta (i.e. 1.0-alpha-1 1.0) but not for Eclipse artifacts. * Carlos in [4] suggested to use exclusions or dependencyManagement. With this approach, POM will quickly become ugly (see for instance ASF Directory Studio POM [6]). Moreover, the actual repo is just unusable because transitive dependencies are not resolved at all due to the current logic. * Using eclipse:to-maven doesn't help [5] So, how to make the Eclipse repo workable for an Eclipse project? A solution could be done in [1], but this might be Eclipse specific. At least, the repo will work :) Thoughts? Vincent [1] http://jira.codehaus.org/browse/MNG-3518 [2] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges [3] http://docs.codehaus.org/display/MAVEN/Versioning [4] http://www.nabble.com/Re%3A-in-repo1-it-is-available-td13950144s177.html#a14708458 [5] http://www.nabble.com/Couldn%27t-find-a-version-when-building-pde-maven-plugin-td16116114s177.html [6] http://svn.apache.org/repos/asf/directory/studio/trunk/pom.xml - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please remove org.apache.myfaces.tobago version 1.0.16 from repo1.maven.org
removed On Thu, Apr 10, 2008 at 12:15 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Thanks Brian, the continuus server deployed to http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Don't trust the wlan during a Lightning Talk. Regards Bernd Brian E. Fox schrieb: -Original Message- From: Bernd Bohmann [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 2:56 PM To: Maven Developers List; MyFaces Development Subject: Please remove org.apache.myfaces.tobago version 1.0.16 from repo1.maven.org Hello, I have prepared the next release of apache-myfaces-tobago during the ApacheCon Europe. Because of a network error I was not able to commit the poms with the next development version. I rollback the release. Unfortunatley the continuus integration server already deployed 1.0.16 to the rsync reposity http://people.apache.org/repo/m1-ibiblio-rsync-repository/ I try to delete all the artifacts on the rsync repository, but the rsync was to fast and has already copied some artifacts. Can someone remove the artifacts for the 1.0.16 from repo1.maven.org. Or what should I do? Regards Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN move on March 29th
On Thu, Mar 20, 2008 at 5:25 AM, Brett Porter [EMAIL PROTECTED] wrote: I wanted to give it a bit of time so 1.0.2 can go out first rather than interrupt that. We also need to move maven-meeper somewhere (I suggest the infrastructure repository). Carlos - wdyt? doesnt really matter as long as i have access ;) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: parameter needed in maven-eclipse-plugin
i have answered to the issue, included here for reference. If you dont like the way the to-maven goal works you need to use the make-artifacts goal, it should do the same but allowing customization The qualifier is an important part of the version, it's not the same 3.3.0.x than 3.3.0.y so if Eclipse releases both versions we are not the people to strip it You can use dependencyManagement section to explicitly set the versions from Maven 2.0.9+ i've given a presentation at EclipseCON talking about this and other problems, will post them soon http://www.jroller.com/carlossg/entry/letters_from_eclipsecon On Tue, Mar 18, 2008 at 3:52 PM, Apaar Trivedi [EMAIL PROTECTED] wrote: Thank you, I have submitted an issue with a patch. http://jira.codehaus.org/browse/MECLIPSE-405 Thanks again, Apaar -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 5:30 PM To: Maven Developers List Subject: Re: parameter needed in maven-eclipse-plugin You can open an issue and attach your patch. We see with carlos if your change seems to be interesting to apply (I think but I'm not an expert). On Tue, Mar 18, 2008 at 11:02 PM, Apaar Trivedi [EMAIL PROTECTED] wrote: We have modified our copy locally and verified that what I am describing can be parameterized and it works. I can provide a patch for review if that is desired, or any feedback from Carlos or Brian would also be helpful. Thanks! Apaar -Original Message- From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 4:59 PM To: Maven Developers List Subject: Re: parameter needed in maven-eclipse-plugin Perhaps Brian or Carlos could have an opinion about it (I think one of them added it). I didn't develop it and never played with this goal, thus I have no idea about it. Arnaud On Tue, Mar 18, 2008 at 9:08 PM, Apaar Trivedi [EMAIL PROTECTED] wrote: Hell, We need one thing parameterized on the EclipseToMavenMojo.java in the maven-eclipse-plugin which should be parameterized anyway. In the call to osgiVersionToMavenVersion, it only allows 'false' to be passed in for the 'strip qualifier' parameter. While the make-artifacts (which extends to-maven) target allows you to strip the qualifier, this is not a parameter that can be used in the to-maven target. This is a problem because using 'to-maven' provides artifacts with the proper names but the dependecies do not resolve due to the qualifiers on the versions. While make-artifacts provides dependecies that resolve but the naming convention of the groupId's and artifactId's is incorrect. Just a parameter -DstripQualifer that gets passed in to the call to osgiVersionToMavenVersion( String version, String forcedQualifier, boolean stripQualifier ) would be perfect. Can I add this as a parameter and get this checked in or can someone do it for me? Aside from not providing proper naming conventions, make-artifacts is deprecated. Thanks for any help Apaar Trivedi O: (512) 469-9300 x 128 Blue Fish Development Group http://www.bluefishgroup.com http://www.bluefishgroup.com/ Blue Fish is Hiring! Check out www.bluefishgroup.com/careers http://www.bluefishgroup.com/careers -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - 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] -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [VOTE] Release Maven Eclipse plugin version 2.5
+1 On Fri, Mar 14, 2008 at 5:30 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, We solved more than 50 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13593styleName=HtmlprojectId=11133 Important changes are : - Add support for WTP 2.0 - Add support for MyEclipse - Improve RAD6 support - Posibility to discover projects in the eclipse workspace And I certainly forgot several others. There are still a lot of issues left in JIRA but we applied all patches which were usable : http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11133status=1 Staging repo: http://people.apache.org/~aheritier/stage/repo/ Staging site: Not yet deployed. I'm looking for a sftp client for leopard Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Restriction.java hashCode and equals not merged into 2.0.x
i've merged just equals and hashcode, I don't know if the other changes should be merged or not. On Mon, Mar 3, 2008 at 5:41 AM, John Casey [EMAIL PROTECTED] wrote: none that I know of. On Mar 3, 2008, at 2:28 AM, Carlos Sanchez wrote: Any reason why revision 614706 from John Casey with Restriction.java hashCode and equals should not be merged in the 2.0.x branch ? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
integration tests in 2.0.x. was: [continuum] BUILD FAILURE: Integration Test Executor
This test seems to work fine in my side. May it be that the 2.0.9 used
is not properly built? should I force a build in maven-core?
On Thu, Mar 1, 0008 at 10:18 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://maven.zones.apache.org/continuum/buildResult.action?buildId=43341projectId=517
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 2 Mar 2008 06:05:12 +
Finished at: Sun 2 Mar 2008 06:18:37 +
Total time: 13m 24s
Build Trigger: Schedule
Build Number: 42
Exit code: 1
Building machine hostname: maven.zones.apache.org
Operating system : SunOS(unknown)
Java Home version :
java version 1.4.2_09
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.2_09-b05)
Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)
Builder version :
Maven version: 2.0.7
Java version: 1.4.2_09
OS name: sunos version: 5.10 arch: x86
SCM Changes:
No files changed
Dependencies Changes:
org.apache.maven.its:core-integration-tests:2.1-SNAPSHOT
Build Defintion:
POM filename: pom.xml
Goals: clean install
Arguments: --batch-mode --non-recursive
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: JDK 1.4.2
Description:
Test Summary:
Tests: 125
Failures: 1
Total time: 778439
Output:
[INFO] Scanning for projects...
[INFO]
[INFO] Building Integration Test Executor
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/export/home/build/data/continuum/checkouts/517/target
[INFO] Deleting directory
/export/home/build/data/continuum/checkouts/517/target/classes
[INFO] Deleting directory
/export/home/build/data/continuum/checkouts/517/target/test-classes
[INFO] Deleting directory
/export/home/build/data/continuum/checkouts/517/target/site
[INFO] [dependency:unpack {execution: default}]
[INFO] Configured Artifact:
org.apache.maven:maven-core:bin:2.0.9-SNAPSHOT:tar.gz
[INFO] Unpacking
/export/home/build/.m2/repository/org/apache/maven/maven-core/2.0.9-SNAPSHOT/maven-core-2.0.9-SNAPSHOT-bin.tar.gzto
/export/home/build/data/continuum/checkouts/517/target/maven-installation
with Includes null and excludes:null
[INFO] Expanding
/export/home/build/.m2/repository/org/apache/maven/maven-core/2.0.9-SNAPSHOT/maven-core-2.0.9-SNAPSHOT-bin.tar.gz
to /var/tmp/tmp24804.tar
[INFO] Expanding: /var/tmp/tmp24804.tar into
/export/home/build/data/continuum/checkouts/517/target/maven-installation
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to
/export/home/build/data/continuum/checkouts/517/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/export/home/build/data/continuum/checkouts/517/target/surefire-reports
Running integration tests for Maven 2.0.7
---
T E S T S
---
Running org.apache.maven.its.Suite
Running integration tests for Maven 2.0.7
(testit).. Ok
0001(testit0001).. Ok
0002(testit0002).. Ok
0003(testit0003).. Ok
0004(testit0004).. Ok
0005(testit0005).. Ok
Restriction.java hashCode and equals not merged into 2.0.x
Any reason why revision 614706 from John Casey with Restriction.java hashCode and equals should not be merged in the 2.0.x branch ? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven Shade plugin 1.0
+1 On Sat, Mar 1, 2008 at 7:20 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi, The Shade plugin is ready to be released. This is needed for the 2.0.9 release as well. We solved 6 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540styleName=Htmlversion=13994 The remaining issues in JIRA are feature requests. Staging repo: http://people.apache.org/~brett/staged-releases/org/apache/maven/plugins/maven-shade-plugin/1.0/ Staging site: http://maven.apache.org/plugins/maven-shade-plugin/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MNG-3410] Plugin managed versions are ignored
On Tue, Feb 26, 2008 at 9:37 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I didnt quite understand this. depMngmt in plugins you use is ignored, so how could you override a plugin dependency using this bug? My understanding of the bug is that if you specify depMgt in _your_ project, it will influence the plugin's classpath. That means you could force a plugin to use a version you want by putting it in your depMgt. no. If you specify depMgt in a plugin and you later use that plugin, the depMgt in the plugin will be ignored other than that what's the overall consensus on fixing this for 2.0.9 ? I vote for fixing it Since we don't currently allow users to override plugin dependencies...fixing this without allowing plugin dep overrides would take away the back door. That's why I suggested we fix them both in the same release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MAVENUPLOAD : jni library best practices ?
In the repo they should have same groupId/artifactId/version and change the type But dont do a bundle. Why don't you put that and the other uploads that you usually do in a repo and I'll setup an automatic sync from there for the groups you contribute On Wed, Feb 27, 2008 at 1:20 AM, nicolas de loof [EMAIL PROTECTED] wrote: I have a requirement to add a LGPL lib to our corporate repo. I'd like to make it also available in maven central. The lib is jNative (http://sourceforge.net/projects/jNative, http://jnative.free.fr/SPIP-v1-8-3/) This is a JNI base library with both a JAR and a dll + so What is the best-practice to bundle such libs and get maven download them ? Can I just package the .dll as jNative-1.3.2.dll in the upload bundle ? Do I just declare two dependencies in my project with same groupId/artifactId/version but != type ? Nico. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MNG-3410] Plugin managed versions are ignored
I didnt quite understand this. depMngmt in plugins you use is ignored, so how could you override a plugin dependency using this bug? other than that what's the overall consensus on fixing this for 2.0.9 ? I vote for fixing it On Tue, Feb 19, 2008 at 1:27 PM, Brian E. Fox [EMAIL PROTECTED] wrote: The only problem is if someone figured out a workaround by specifying in depMgt specifically to override the plugin rev. We should fix this + the ability to override a plugin's dependency version in the same release so people at least have an option. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Tuesday, February 19, 2008 3:57 PM To: Maven Developers List Subject: Re: [MNG-3410] Plugin managed versions are ignored I dont think is related, this bug only affects plugins that use dependencyManagement. It does nothing with the plugin dependencies. This wold change plugin classpath for all those plugins that have dependency management, but it will change them to what the plugin was successfully built with, so I don't think it should be a huge problem to put it for 2.0.x On Feb 19, 2008 9:56 AM, Niall Pemberton [EMAIL PROTECTED] wrote: On Feb 19, 2008 5:46 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: On Feb 19, 2008 9:40 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:36 AM, Carlos Sanchez wrote: I think you misunderstood. The dependencyManagement is used for project dependencies, fine with that. When you use a plugin no dependencyManagement is applied. The current project depMan shouldn't be applied because it's only for projects, so that's ok. The problem comes when a plugin is built using dependencyManagement to force some dependencies. When that plugin is used, the dependencyManagement of the plugin is ignored, so you run it with different dependencies than the ones you build it with. So there is no Map used during the plugin's artifact resolution at runtime is what you're saying, yes? right, and I think it should use the plugin Map that was used during the plugin build Perhaps related, but I tried specifying a later version of a plugin's dependency and it was ignored: See http://maven.markmail.org/message/km5mlcfsgqlo7le2 Niall On Feb 19, 2008 9:24 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:07 AM, Carlos Sanchez wrote: On Feb 19, 2008 7:46 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. Dependency management should not affect anything to do with plugins. If that is happening that is completely wrong. Dependencies and what plugins use should be completely separate. A project's classpath should never affect what is used in a plugin's execution. it is, the problem is dependencyManagement in the plugin pom Then somewhere the Map that is used for managed dependencies is getting fed into both the project's resolution and the plugin's resolution and that definitely needs to be separated. Even if we decide there are certain cases where they should be shared (and I can't actually think of any real cases except for maybe Antlr vX generated code needing Antlr vX runtime code which needs to be aligned) they should be separate so we knowingly combine them if necessary. Problem is if you find that shared Map what are we going to break if you separate them now? Just thinking aloud. eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath dependencyManagement in your POM or in the plugin's POM? dependencyManagement in plugin's pom (A) If you use plugin A in your pom it will be used with C version 1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [OT] Re: An experiment with Spring... What about OSGi ?
spring has good integration with OSGi to enable Spring beans to be
OSGi services.
On Mon, Feb 25, 2008 at 11:05 AM, Ludovic Maitre [EMAIL PROTECTED] wrote:
Hi Brett, all,
Have you considered using OSGi instead of [Plexus|Spring] ? I'm not an
expert of one or the other, but i try to do some projects with OSGi
since a few months and i like it.
Best regards,
Brett Porter a écrit :
Hi,
Given the discussion yesterday, I played around with some changes on a
branch when I got up early this morning to show how we could do a
partial migration to Spring without having to do it all at once.
https://svn.apache.org/repos/asf/maven/archiva/branches/springy
This shows:
- ability to lookup plexus components via spring IoC
- ability to lookup spring beans during the Plexus component lifecycle
- basic functional setup for Spring in the Archiva application
Eventually, as whole subsystems no longer require plexus it will be
possible to clean it up, such as:
- get rid of the additional lookups
- use annotations for configuration
- use testng + get/set + mocks for the tests where possible (and
spring testcontext where integration testing is needed)
Here is how to obtain a plexus object from Spring (note there is some
pre-req setup in test cases you'll see in the commit, as there is in
the additional servlet listener):
bean id=urlCache factory-bean=plexusCacheFactory
factory-method=createInstance /
bean id=plexusCacheFactory
class=org.apache.maven.archiva.common.spring.PlexusFactory
constructor-arg index=0 value=org.codehaus.plexus.cache.Cache/
constructor-arg index=1 value=url-failures-cache/
/bean
To get a spring bean inside a plexus component, it is like this (make
sure to implement Initializable):
/**
* @plexus.requirement
*/
private SpringFactory springFactory;
public void initialize()
throws InitializationException
{
urlFailureCache = (UrlFailureCache) springFactory.lookup(
urlFailureCache );
}
The next thing we should probably try is using something like
SpringCache as suggested to remove the plexus-cache dependency.
Have fun!
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
--
Cordialement,
Ludo - http://www.ubik-products.com
---
L'amour pour principe et l'ordre pour base; le progres pour but (A.Comte)
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Getting a mojo instance from the embedder
Is it possible to get a Mojo instance from the embedder ? I started with getPlexusContainer().lookup(org.apache.maven.plugin.Mojo.ROLE,resources:resources) and of course didnt work, I guess you'd need the embedder to process the lifecycle first so the Mojos are available. Any hints? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration not selected properly when a plugin is specified multiple times in the pom.
related to MNG-1701 ? On Fri, Feb 22, 2008 at 1:15 PM, Ryan Ovrevik [EMAIL PROTECTED] wrote: Thanks! You reiterated my thoughts almost exactly. Forcing executions into arbitrary adjacent phases will work fine… it just seems ugly. thanks, rovrevik On Fri, Feb 22, 2008 at 3:35 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Ryan, So what you are trying to achieve is control the ordering of executions within a single phase? Ie you want: Phase X: (1) plugin A (2) plugin B (3) plugin A again Yes, I think this is not currently possible to achieve with execution blocks. There is some discussion about providing better control over plugin ordering for maven2.1. Maybe this needs to go on the list of use-cases. If the second execution of A was actually done via a different plugin, then achieving this would be simple; the order of plugins in the pom is the order of bindings to the phase. It does seem a little odd that simply because step 3 happens to use a plugin that has already been used in the pom that the mechanism for configuring it is suddenly radically different (multiple execution tags, not multiple plugin tags). An alternative that stays with the executions approach could be to add an extra property of an execution declaration that says whether to add it to the tail of the plugin-list for the phase (default) or the head. Then for your case, first declare plugin B then mark the first execution of plugin A head and the second tail (default). Perhaps this could be done by something like: phaseintegration-test;head/phase without needing a POM format change? This still Or perhaps an execution could be marked as before the execution with id X which might be a more explicit way of declaring inter-execution dependencies. Then plugin B could be declared as being before the excution for (3). Cramming this into the existing execution configuration elements doesn't seem easy though. Maybe phaseintegration-test;before=maven-A-plugin:execStep3/phase although that syntax is rather ugly... To me, the approach of simply allowing multiple plugin declarations looks at least as simple as the above suggestions though. And can be implemented (as you show) without POM syntax changes. But for now it seems to me that using different phases is your best solution..and hoping that there are suitable phases in the lifecycle available to be used. In your case, are pre-integration-test and post-integration-test suitable? Regards, Simon (PS: I'm just a maven user, not a developer..) Ryan Ovrevik schrieb: Yeah, thanks, I know about using multiple executions. It is a shame that you have to put an execution in an arbitrary phase just to make the configuration behave (at least it seems that way to me). The use case that I have fits very nicely into generate-test-resources to export date from a source database and process-test-resources to import the data into the target database. If using additional phases is the way that it has to be… oh well. For what it is worth… The patch is trivial and has not broken any of the other maven projects that I have built with it. Thanks, rovrevik On Thu, Feb 21, 2008 at 11:00 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Put multiple execution blocks inside the executions. You would probably need to use two phases though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Ovrevik Sent: Thursday, February 21, 2008 10:19 PM To: dev@maven.apache.org Subject: Re: Configuration not selected properly when a plugin is specified multiple times in the pom. I was specifying a plugin twice with-in a profile to control the order of operations across two plugins with in a particular phase. The scenario is as follows (simplified): * Use sql-maven to drop and create a database. * Use dbunit to import some data. * Use sql-unit again to drop some columns on the imported data. If you do not specify the plugin twice, how would you do this? rovrevik IIRC, model validation happens after inheritance and profile injection, to ensure the project has every opportunity to fill in missing sections. So, performing this sort of check in the model validator would be appropriate. I added a check for duplicate dependencies recently, IIRC, and this is similar. -john On Feb 21, 2008, at 10:26 AM, Brian E. Fox wrote: I was thinking this was across multiple poms (inheritance) but yes in the same pom that's not good.
Re: Apache Continuum is now an Apache top level project
nice! On Wed, Feb 20, 2008 at 12:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Hi all, Congratulations - the board passed the resolution we submitted. We'll have some work to do to get set up over the next month, but other than that it's business as usual. Certainly shouldn't interrupt the planning for the next release :) Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: propagating to repo1?
got it, please check in 4 hours, should be fixed now On Feb 20, 2008 9:57 AM, Dan Fabulich [EMAIL PROTECTED] wrote: cc: [EMAIL PROTECTED] Dan Fabulich wrote: I staged Surefire 2.4.2 last night about 12 hours ago; it still hasn't shown up on repo1. http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire/ http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/maven/surefire/surefire/ This seems longer than usual. Is the rsync still working correctly? -Dan - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MNG-3410] Plugin managed versions are ignored
On Feb 19, 2008 7:46 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. Dependency management should not affect anything to do with plugins. If that is happening that is completely wrong. Dependencies and what plugins use should be completely separate. A project's classpath should never affect what is used in a plugin's execution. it is, the problem is dependencyManagement in the plugin pom eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath dependencyManagement in your POM or in the plugin's POM? dependencyManagement in plugin's pom (A) If you use plugin A in your pom it will be used with C version 1.0 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A language that doesn't affect the way you think about programming is not worth knowing. -— Alan Perlis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MNG-3410] Plugin managed versions are ignored
I think you misunderstood. The dependencyManagement is used for project dependencies, fine with that. When you use a plugin no dependencyManagement is applied. The current project depMan shouldn't be applied because it's only for projects, so that's ok. The problem comes when a plugin is built using dependencyManagement to force some dependencies. When that plugin is used, the dependencyManagement of the plugin is ignored, so you run it with different dependencies than the ones you build it with. On Feb 19, 2008 9:24 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:07 AM, Carlos Sanchez wrote: On Feb 19, 2008 7:46 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. Dependency management should not affect anything to do with plugins. If that is happening that is completely wrong. Dependencies and what plugins use should be completely separate. A project's classpath should never affect what is used in a plugin's execution. it is, the problem is dependencyManagement in the plugin pom Then somewhere the Map that is used for managed dependencies is getting fed into both the project's resolution and the plugin's resolution and that definitely needs to be separated. Even if we decide there are certain cases where they should be shared (and I can't actually think of any real cases except for maybe Antlr vX generated code needing Antlr vX runtime code which needs to be aligned) they should be separate so we knowingly combine them if necessary. Problem is if you find that shared Map what are we going to break if you separate them now? Just thinking aloud. eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath dependencyManagement in your POM or in the plugin's POM? dependencyManagement in plugin's pom (A) If you use plugin A in your pom it will be used with C version 1.0 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A language that doesn't affect the way you think about programming is not worth knowing. -— Alan Perlis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MNG-3410] Plugin managed versions are ignored
On Feb 19, 2008 9:40 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:36 AM, Carlos Sanchez wrote: I think you misunderstood. The dependencyManagement is used for project dependencies, fine with that. When you use a plugin no dependencyManagement is applied. The current project depMan shouldn't be applied because it's only for projects, so that's ok. The problem comes when a plugin is built using dependencyManagement to force some dependencies. When that plugin is used, the dependencyManagement of the plugin is ignored, so you run it with different dependencies than the ones you build it with. So there is no Map used during the plugin's artifact resolution at runtime is what you're saying, yes? right, and I think it should use the plugin Map that was used during the plugin build On Feb 19, 2008 9:24 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:07 AM, Carlos Sanchez wrote: On Feb 19, 2008 7:46 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. Dependency management should not affect anything to do with plugins. If that is happening that is completely wrong. Dependencies and what plugins use should be completely separate. A project's classpath should never affect what is used in a plugin's execution. it is, the problem is dependencyManagement in the plugin pom Then somewhere the Map that is used for managed dependencies is getting fed into both the project's resolution and the plugin's resolution and that definitely needs to be separated. Even if we decide there are certain cases where they should be shared (and I can't actually think of any real cases except for maybe Antlr vX generated code needing Antlr vX runtime code which needs to be aligned) they should be separate so we knowingly combine them if necessary. Problem is if you find that shared Map what are we going to break if you separate them now? Just thinking aloud. eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath dependencyManagement in your POM or in the plugin's POM? dependencyManagement in plugin's pom (A) If you use plugin A in your pom it will be used with C version 1.0 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A language that doesn't affect the way you think about programming is not worth knowing. -— Alan Perlis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [MNG-3410] Plugin managed versions are ignored
I dont think is related, this bug only affects plugins that use dependencyManagement. It does nothing with the plugin dependencies. This wold change plugin classpath for all those plugins that have dependency management, but it will change them to what the plugin was successfully built with, so I don't think it should be a huge problem to put it for 2.0.x On Feb 19, 2008 9:56 AM, Niall Pemberton [EMAIL PROTECTED] wrote: On Feb 19, 2008 5:46 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: On Feb 19, 2008 9:40 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:36 AM, Carlos Sanchez wrote: I think you misunderstood. The dependencyManagement is used for project dependencies, fine with that. When you use a plugin no dependencyManagement is applied. The current project depMan shouldn't be applied because it's only for projects, so that's ok. The problem comes when a plugin is built using dependencyManagement to force some dependencies. When that plugin is used, the dependencyManagement of the plugin is ignored, so you run it with different dependencies than the ones you build it with. So there is no Map used during the plugin's artifact resolution at runtime is what you're saying, yes? right, and I think it should use the plugin Map that was used during the plugin build Perhaps related, but I tried specifying a later version of a plugin's dependency and it was ignored: See http://maven.markmail.org/message/km5mlcfsgqlo7le2 Niall On Feb 19, 2008 9:24 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 19-Feb-08, at 9:07 AM, Carlos Sanchez wrote: On Feb 19, 2008 7:46 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 18-Feb-08, at 11:54 PM, Carlos Sanchez wrote: I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. Dependency management should not affect anything to do with plugins. If that is happening that is completely wrong. Dependencies and what plugins use should be completely separate. A project's classpath should never affect what is used in a plugin's execution. it is, the problem is dependencyManagement in the plugin pom Then somewhere the Map that is used for managed dependencies is getting fed into both the project's resolution and the plugin's resolution and that definitely needs to be separated. Even if we decide there are certain cases where they should be shared (and I can't actually think of any real cases except for maybe Antlr vX generated code needing Antlr vX runtime code which needs to be aligned) they should be separate so we knowingly combine them if necessary. Problem is if you find that shared Map what are we going to break if you separate them now? Just thinking aloud. eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath dependencyManagement in your POM or in the plugin's POM? dependencyManagement in plugin's pom (A) If you use plugin A in your pom it will be used with C version 1.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[MNG-3410] Plugin managed versions are ignored
I'd like to get some feedback in MNG-3410, particularly from John as he has been working on this. If you build and install a plugin with managed versions that affect plugin transitive dependencies, when it's used the dependency management is ignored If the dependency management affects the plugin direct dependecies it works properly because the information is merged. eg. Plugin A depends on jar B that depends on jar C[1.0] A dependencyManagement explicitly forces C[2.0], you build and install using C[2.0] in the classpath If you use plugin A in your pom it will be used with C version 1.0 -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't run Maven 2.1 Snapshot
I saw that problem before and IIRC it was a problem wiht my M2_HOME and PATH, both were not in sync pointing to the same 2.1-snapshot On Fri, Feb 15, 2008 at 10:26 AM, Rahul Thakur [EMAIL PROTECTED] wrote: I get the error below when I attempt to build and run a Maven 2.1 SNAPHOT on win xp. Rahul E:\maven-componentsmvn -X package Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher Caused by: java.lang.ClassNotFoundException: org.codehaus.classworlds.Launcher at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
Reading carefully the javadoc I see the mistakes i made in clone :( I
can fix that
The problem arised with a delegate pattern implementation, the
MavenProject instance is encapsulated [1], but the problem comes with
other classes using this constructor to make copies, which will ignore
any customizations made in the delegating object (the subclass).
If the way to make a copy where defined in a method ( clone() seems to
be the right one ) then subclasses could just override that method and
there wouldnt be any need of getters/setters, but right now that
constructor is used in the maven archiver. Adding the getters and
setters is a patch until the other classes are updated to use clone()
and to keep backwards compatibility.
[1] http://tinyurl.com/29jzte
On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED] wrote:
Carlos,
Can you elaborate on the need for this?
I understand that since MavenProject is non-final and so are the get/
sets they can be overridden and so we should be using the get/set
internally. However, it would seem we don't need that funcationality
for every field - which particular ones do you see as needing to be
overridden?
Also, I don't think the clone() stuff is right:
- you've deprecated the copy constructor even though it is still
useful. You also require it's existence which means it shouldn't be
deprecated.
- clone()'s contract says that it doesn't call any constructors,
making the method work but not as documented by the JDK
- clone() should call super.clone() to get a valid MavenProject instance
- MavenProject doesn't implement clonable
Why did you need clone()?
Thanks,
Brett
On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Feb 13 22:40:35 2008
New Revision: 627675
URL: http://svn.apache.org/viewvc?rev=627675view=rev
Log:
[MNG-3400] MavenProject is not extensible. Merge rev 627670 from trunk
Modified:
maven/components/branches/maven-2.0.x/maven-project/src/main/java/
org/apache/maven/project/MavenProject.java
maven/components/branches/maven-2.0.x/maven-project/src/test/java/
org/apache/maven/project/MavenProjectTest.java
Modified: maven/components/branches/maven-2.0.x/maven-project/src/
main/java/org/apache/maven/project/MavenProject.java
URL:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?rev=627675r1=627674r2=627675view=diff
=
=
=
=
=
=
=
=
==
--- maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java (original)
+++ maven/components/branches/maven-2.0.x/maven-project/src/main/
java/org/apache/maven/project/MavenProject.java Wed Feb 13 22:40:35
2008
@@ -158,103 +158,107 @@
model.setArtifactId( EMPTY_PROJECT_ARTIFACT_ID );
model.setVersion( EMPTY_PROJECT_VERSION );
-this.model = model;
+this.setModel( model );
}
public MavenProject( Model model )
{
-this.model = model;
+this.setModel( model );
}
+/**
+ * @deprecated use [EMAIL PROTECTED] #clone()}
+ */
public MavenProject( MavenProject project )
{
// disown the parent
// copy fields
-this.file = project.file;
+setFile( project.getFile() );
-// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be sure!
-if ( project.dependencyArtifacts != null )
+// don't need a deep copy, they don't get modified or added/
removed to/from - but make them unmodifiable to be
+// sure!
+if ( project.getDependencyArtifacts() != null )
{
-this.dependencyArtifacts =
Collections.unmodifiableSet( project.dependencyArtifacts );
+
setDependencyArtifacts
( Collections.unmodifiableSet( project.getDependencyArtifacts() ) );
}
-
-if ( project.artifacts != null )
+
+if ( project.getArtifacts() != null )
{
-this.artifacts =
Collections.unmodifiableSet( project.artifacts );
+
setArtifacts( Collections.unmodifiableSet( project.getArtifacts() ) );
}
-
-if ( project.pluginArtifacts != null )
+
+if ( project.getPluginArtifacts() != null )
{
-this.pluginArtifacts =
Collections.unmodifiableSet( project.pluginArtifacts );
+
setPluginArtifacts
( Collections.unmodifiableSet( project.getPluginArtifacts() ) );
}
-
-if ( project.reportArtifacts != null )
+
+if ( project.getReportArtifacts() != null )
{
-this.reportArtifacts =
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
The archiver doesnt have to understand eclipse. But it can't create a MavenProject object when the one passed is a subclass that may have customized behavior On Thu, Feb 14, 2008 at 5:42 PM, Brian E. Fox [EMAIL PROTECTED] wrote: It seems curious to me that the archiver needs to understand eclipse. Isn't this a generic component? Perhaps you should be making maven-eclipse-archiver or something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, February 14, 2008 5:41 PM To: Maven Developers List Subject: Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any Previous to my patch new MavenProject(project) fails with NPE as the fields are accessed directly. After the patch it works, although I still think to make copies it should use clone() and that's why I deprecated the constructor what @todo are you talking about? I will fix the clone method. On Thu, Feb 14, 2008 at 5:17 PM, Brett Porter [EMAIL PROTECTED] wrote: I'm not sure why the archiver needs to use the delegate? Is it because you lose track of the updates? IF that's all, then you could follow the @todo in the class javadoc :) If it truly needs it, clone is the right method - I'd definitely recommend reading the section on clone in Effective Java though :) - Brett On 15/02/2008, at 11:57 AM, Carlos Sanchez wrote: Reading carefully the javadoc I see the mistakes i made in clone :( I can fix that The problem arised with a delegate pattern implementation, the MavenProject instance is encapsulated [1], but the problem comes with other classes using this constructor to make copies, which will ignore any customizations made in the delegating object (the subclass). If the way to make a copy where defined in a method ( clone() seems to be the right one ) then subclasses could just override that method and there wouldnt be any need of getters/setters, but right now that constructor is used in the maven archiver. Adding the getters and setters is a patch until the other classes are updated to use clone() and to keep backwards compatibility. [1] http://tinyurl.com/29jzte On Thu, Feb 14, 2008 at 4:15 PM, Brett Porter [EMAIL PROTECTED] wrote: Carlos, Can you elaborate on the need for this? I understand that since MavenProject is non-final and so are the get/ sets they can be overridden and so we should be using the get/set internally. However, it would seem we don't need that funcationality for every field - which particular ones do you see as needing to be overridden? Also, I don't think the clone() stuff is right: - you've deprecated the copy constructor even though it is still useful. You also require it's existence which means it shouldn't be deprecated. - clone()'s contract says that it doesn't call any constructors, making the method work but not as documented by the JDK - clone() should call super.clone() to get a valid MavenProject instance - MavenProject doesn't implement clonable Why did you need clone()? Thanks, Brett On 14/02/2008, at 5:40 PM, [EMAIL PROTECTED] wrote: Author: carlos Date: Wed Feb 13 22:40:35 2008 New Revision: 627675 URL: http://svn.apache.org/viewvc?rev=627675view=rev Log: [MNG-3400] MavenProject is not extensible. Merge rev 627670 from trunk Modified: maven/components/branches/maven-2.0.x/maven-project/src/main/java/ org/apache/maven/project/MavenProject.java maven/components/branches/maven-2.0.x/maven-project/src/test/java/ org/apache/maven/project/MavenProjectTest.java Modified: maven/components/branches/maven-2.0.x/maven-project/src/ main/java/org/apache/maven/project/MavenProject.java URL: http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven -project/src/main/java/org/apache/maven/project/MavenProject.java?rev=62 7675r1=627674r2=627675view=diff = = = = = = = = = = --- maven/components/branches/maven-2.0.x/maven-project/src/main/ java/org/apache/maven/project/MavenProject.java (original) +++ maven/components/branches/maven-2.0.x/maven-project/src/main/ java/org/apache/maven/project/MavenProject.java Wed Feb 13
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
I dont know why it is there, but it is, line 314 https://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/main/java/org/apache/maven/archiver/MavenArchiver.java?annotate=627672 emmanuel comment is we have to clone the project instance so we can write out the pom with the deployment version, without impacting the main project instance... On Thu, Feb 14, 2008 at 5:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r627675 - in /maven/components/branches/maven-2.0.x/maven-project/src: main/java/org/apache/maven/project/MavenProject.java test/java/org/apache/maven/project/MavenProjectTest.java
does this look better? https://svn.apache.org/viewvc/maven/components/trunk/maven-project/src/main/java/org/apache/maven/project/MavenProject.java?r1=627670r2=627932pathrev=627932diff_format=h On Thu, Feb 14, 2008 at 6:11 PM, Brett Porter [EMAIL PROTECTED] wrote: Ok, well in that case you don't need clone, you just needed to flip all the get/set's like you did and continue using the copy constructor. On 15/02/2008, at 12:59 PM, Carlos Sanchez wrote: I dont know why it is there, but it is, line 314 https://svn.apache.org/viewvc/maven/shared/trunk/maven-archiver/src/main/java/org/apache/maven/archiver/MavenArchiver.java?annotate=627672 emmanuel comment is we have to clone the project instance so we can write out the pom with the deployment version, without impacting the main project instance... On Thu, Feb 14, 2008 at 5:51 PM, Brett Porter [EMAIL PROTECTED] wrote: On 15/02/2008, at 12:41 PM, Carlos Sanchez wrote: The archiver is making a copy of the MavenProject using newProject = new MavenProject(project) project is a subclass of MavenProject (EclipseMavenProject) Instead the archiver should do project.clone() if any I think I was asking the same thing as Jason - I didn't know why the archiver should be creating a new project (and if it was, why it would need to be another instance of the delegate class). what @todo are you talking about? I meant in the other code, but it's not relevant since you aren't doing this for lack of update visibility. - Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin Versions in the Super pom
I'm pretty much +1 Another behavior that would change is if I build and install a plugin in my local repo, it won't be used. I'd have to explicitly set it in the pom. On Feb 8, 2008 4:41 PM, Brian E. Fox [EMAIL PROTECTED] wrote: I know it's been discussed before in the context of various other issues and solutions, but I want to discuss locking down core plugins in the super pom _for_ 2.0 _only_. Normally we get into some large protracted discussions about better solutions and drawbacks/benefits of them, meanwhile the users suffer the wrath of auto plugin updates. Considering the amount of time I spent writing the enforcer requirePluginVersions rule, you can safely assume you don't need to convince me that the _right_ way is to lock them down in your poms. I already believe that. I also think that there is probably a better solution, whether it's plugin packs (which I don't agree with at this point) or something else. We can agree that whatever else it is that may be done will come in 2.1 and for a large portion of users 2.1 in production is a long way off and we continue to suffer bad press about the instability of Maven in the mean time. So I'd like to put those discussions aside for now and simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. I see two main benefits: 1. Those who have followed best practice and locked their versions down will not be affected by this at all. The normal inheritance rules will apply, and we'll put these versions into the pluginManagement section of the super pom. 2. Those who have not locked their versions down will only be affected by gaining stability in between maven releases. If they want a new plugin before the next Maven release, they will have to follow the best practices and lock their version down to the new version. (this actually informs people and encourages them to learn how to do that...but when _they_ are ready to do it because they are motivated to grab a new release, not when they least expect it because we pushed out a plugin that broke their build) 3. The change is very simple, can be done quickly and has little harm of creating more problems. The only drawback I can see is that it lulls people into a false sense of security because _less_ plugins auto update Not all of them. Certainly we won't lock down every plugin in existence and those plugins will still be subjected to the auto update. Again, I'm not suggesting we solve the world here, but this is a simple step forward to reduce the impact of one of the most frequent complaints of the users. If you can think of some serious drawbacks to this approach, speak now for forever hold your peace ;-) --Brian -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mirroring question
http://maven.apache.org/guides/mini/guide-mirror-settings.html On Feb 7, 2008 10:39 AM, Tiffney, Lisa S. [EMAIL PROTECTED] wrote: Classification: UNCLASSIFIED Good afternoon I have a requirement to provide a mirror of http://repo1.maven.rg/maven2/ on our secure internal site. A couple of basic questions; can we receive permission to do this and if so what is the easiest way to accomplish this. ( I am new at this). What else do you require from us? Our internal site as mentioned is a secure site with no connection whatsover to the internet. Appreciate your earliest response. Cheers, Lisa Lisa Tiffney www.cse-cst.gc.ca Communications Security Establishment (CSE) Ottawa, On [EMAIL PROTECTED] 613-991-7854 613-668-2469(cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: groupID for SUN web service developer pack Jars ?
maybe com.sun.org.apache.xmlsec but doesnt really matter that much On Feb 7, 2008 2:36 AM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I need some jars from archived SUN WSDP ( http://java.sun.com/webservices/downloads/1.5/index.html) What is the recommended groupId for such jars ? For example, xmlsec.jar is a sun-repackaged apache xml-security. - com.sun.xmlsec ? - com.sun.org.apache.xmlsec (repository allready contains com/sun/org/apache/jaxp-ri/) - ?? Nico -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discussion] Continuum 2.0 Roadmap
well, if you want to have a plugin based architecture, what better that OSGi? and it may help too for distributiion of build machines On Feb 6, 2008 2:08 AM, Rahul Thakur [EMAIL PROTECTED] wrote: Are you thinking what I am thinking - an OSGi based runtime underneath and plugins/extensions that could be loaded runtime? :-) Carlos Sanchez wrote: Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: [Discussion] Continuum 2.0 Roadmap
Some comments Database vs xml: definitely database. Throwing away the db access api (JDO/JPA/...) now that it's already there doesnt make much sense. Maybe there are implementations that use xml for storage and that's where you'd need to look if you want file storage Spring vs Guice vs Plexus: Spring for sure. Big community, lots of users, documentation, support,... Specially if you want to add JMX support (can be done really easily just with annotations using reflection), and thinking in OSGi in the future I'm sure it will be really easy to integrate Spring and OSGi if it is not already. I'd start softly, just migrating thing that would require adding features to plexus, and move from there. I agree with Brett on having 1.2, 1.3,... it's good to have a list of what you want to do for 2.0 but as it gets done it should be released in minor versions. On Jan 29, 2008 2:34 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote: Hi I started a document [1] with my ideas about Continuum 2. As you can see in this doc, I want to add lot of things in the next version. Feel free to comment on it. [1] http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion Emmanuel -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Tree/graph of Artifact objects
It's a graphical view of the graph ;) On Jan 31, 2008 8:19 PM, David Blevins [EMAIL PROTECTED] wrote: On Jan 29, 2008, at 10:48 AM, Carlos Sanchez wrote: if you want something graphical take a look at http://code.google.com/p/maven-dependency-browser/ it's going to be integrated in Q4E http://code.google.com/p/q4e/issues/detail?id=144 Graph as in the data structure, but thanks :) -David On Jan 18, 2008 12:15 PM, David Blevins [EMAIL PROTECTED] wrote: Is there any way to get or make a tree of Artifact objects? I've tried taking the list of Artifacts returned from project.getArtifacts(), then wrapping them in my own node object and relinking them via the info in the dependency trail. This works fine except that there is some information loss. Say two artifacts (a and b) each depend on a thrid artifact (c). The c dependency will have only one dependency trail showing either a or b and i'd like to see both trails. I don't really need this info from the dependency trail specifically, just want some way to get the whole graph with no loss in relationships. Any ideas? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project level exclusions
sounds like there are other 44 people that agrees with you ;) http://jira.codehaus.org/browse/MNG-1977 On Jan 28, 2008 11:16 PM, David Blevins [EMAIL PROTECTED] wrote: It occurs to me I'd really like the ability to apply exclusions at a more general level than each individual dep. We have ton of excludes (136), some deps want to pull in the world, and a very good chunk of them are redundant. Doing a grep/sort/uniq looks like 68 of them are redundant. We use the dependencyManagement section in our parent pom quite a bit (most our excludes are there), but perhaps it would be logical also use the dependencyManagement, which simplifies inclusion, to simplify exclusion as well. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tree/graph of Artifact objects
if you want something graphical take a look at http://code.google.com/p/maven-dependency-browser/ it's going to be integrated in Q4E http://code.google.com/p/q4e/issues/detail?id=144 On Jan 18, 2008 12:15 PM, David Blevins [EMAIL PROTECTED] wrote: Is there any way to get or make a tree of Artifact objects? I've tried taking the list of Artifacts returned from project.getArtifacts(), then wrapping them in my own node object and relinking them via the info in the dependency trail. This works fine except that there is some information loss. Say two artifacts (a and b) each depend on a thrid artifact (c). The c dependency will have only one dependency trail showing either a or b and i'd like to see both trails. I don't really need this info from the dependency trail specifically, just want some way to get the whole graph with no loss in relationships. Any ideas? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
from m1 syncing partners that didnt have poms On Jan 28, 2008 11:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez 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 On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: 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
Re: Fix missing POM files
I still don't see what's wrong with that. I know it can break your build, but people don't think those [WARN] messages in the cmdline and the fact that maven is hitting the internet trying to download the missing pom everytime, are the sign of a problem ??? On Jan 28, 2008 11:48 AM, Daniel Kulp [EMAIL PROTECTED] wrote: On Monday 28 January 2008, Jason van Zyl wrote: On 28-Jan-08, at 11:30 AM, Daniel Kulp wrote: What's worse is if someone reports a missing pom, they then go and add a FULL pom with deps which then gets synced to central. That could cause issues as we all know. Are you serious? Yep. They did it for neethi just last week. Look at the time stamps at: http://repo1.maven.org/maven2/org/apache/neethi/neethi/2.0.2/ Dan Dan On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez 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 On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: 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
Re: Fix missing POM files
There's still around 5 releases every month only at apache that go to the m1 repo (most of them with poms). I'd rather have the official jars being deployed without poms than do it manually, and accept anybody's upload request for let's say Tomcat, with all the problems that it could cause. . On Jan 28, 2008 11:39 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 28-Jan-08, at 11:33 AM, Carlos Sanchez wrote: from m1 syncing partners that didnt have poms We should just shut off the m1 conversion. Happy to support the m1 repository mapping, but that process is broken not to mention it pegs the machine when it runs. On Jan 28, 2008 11:25 AM, Jason van Zyl [EMAIL PROTECTED] wrote: How did anything without a POM get into the m2 repository? From the m1 conversion (which we should turn off now)? From syncing partners? On 28-Jan-08, at 11:10 AM, Carlos Sanchez wrote: i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez 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 On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: 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
Re: Fix missing POM files
given these premises - pom is not in the repo - project is not willing to put it then authoritative data can come from project users, after all this is a community. As i said before my opinion is that we can still put poms in projects that didnt have them On Jan 28, 2008 11:27 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
i'm talking about things that are already there without pom On Jan 28, 2008 11:07 AM, Jason van Zyl [EMAIL PROTECTED] wrote: If there is no POM you should just reject it and send it back. If we automated this, which we will, it would fail. You can't know as a third party what is correct. On 28-Jan-08, at 10:51 AM, Carlos Sanchez 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 On Jan 28, 2008 8:19 AM, Tamás Cservenák [EMAIL PROTECTED] wrote: 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
Re: Fix missing POM files
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? there's still people saying that poms should be modifiable! and the fact that maven is ready for business doesnt mean taht you can use anything however you want, you should enforce policies on what plugin versions you want, what third party libraries,... because we may take decisions here that will affect the decisions at some companies, while not at others. Many times there's not black or white On Jan 25, 2008 4:16 PM, Joerg Hohwiller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am sometimes late on threads but anyways... | i don't agree, the point of not having a pom there is to be able to | add one later with the right info. If you work against something | without pom, hey, it's your decision, but you are aware that it's a | problem, as all the warnings tell you I do NOT agree. Adding a jar and later some pom with dependencies is odd. You should enforce that no artifacts can go to central repro if they do not come with a proper pom. To fix the actual problem default poms should be added to the repository. Further versions of these artifacts can add the correct dependencies. Please consider that maven is not just used by open-source users for fun but also by brute business. If some company is running a deployment that comes to a wrong result because of dependencies in a pom that was just added to the repository (e.g. because then a different version than before was chosen for a dependent artifact), they will flame maven. Don't we say that maven is also ready for business? Do you have an idea how much harm the maven community has done to enterprise (and other) users by releasing buggy plugins? I do not want to blame anybody! Giving your spare time for open-source is worth some honor and humans make mistakes. But we should be aware of the sensibility of our decisions. Best regards ~ Jörg | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | Isn't the goal here to stop incessant warnings during a build about | trying to downalod a missing POM? | | The way to do that is to that is to upload a POM for that artifact to | the repository. | | But Nico is right is that the uploaded POM should not break existing | builds. Which means that the POM just needs to be bare bones and list no | dependencies as the missing POM introduces no deps. | | So Nico, I'd suggest you create a simple POM with just groupId, | artifactId and version and get it uploaded to the repository. | | Can I also suggest that it is a worthy task to auto generate and upload | such POMs for all artifacts in central with a missing POM. | | William | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | Sanchez | Sent: Tuesday, 16 October 2007 2:01 AM | To: Maven Developers List | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | different SMTP TO: and MIME TO: fields in the email addresses | | sorry, but that's not the case currently. If it has no metadata it can | be added, that's why you get warnings when the metadata is missing. | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I fully agree about collaborating and submitting more artifacts to the | repo with good meta-datas. The only issue I can see is about | reproductible builds if those meta-datas change. | | The established rule NOT to change meta-datas after publication | applies IMHO also to artifacts without meta-datas. Anyone providing | metadatas for an artifact that is allready in repo, so that can be | used by many people, will potentialy break there builds, with no way | in maven2 to quickly fix this issue by stopping the transitive | dependencies. | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm | also | not | the guy who used it in the project. I came later and have to | maintain | the | project now. | that's collaboration ;) if you want to use something that uses | castor and want to do it the right way, yes you should contribute a | pom | | Do you think I should contribute an empty POM just to ensure | no-one can latter contribute one with some (maybe) unexpected | dependencies ? | not an empty pom, but it shouldn't take more than 10 min to figure | out what the dependencies are | | A better solution IMHO should be to have an option for a | dependency in | my | POM to excludes all transitive dependencies. The current | exclusion elements require to list dependencies. With such a | feature, a project | that | has legacy reference on a dependency with no POM can simply set | no-transitivity to be reproductible in any case. | that's already filled in jira | | Many artifacts
Re: Can somebody check the permissions on repo1.maven.org? (groupId asm)
fixed in central
the address to notify of such things is
[EMAIL PROTECTED] or open an issue in jira MEV
And you have the emails of the maintainers in
https://svn.apache.org/repos/asf/maven/archiva/tools/trunk/maven-meeper/src/bin/synchronize/m2-sync/sync.csv
On Jan 23, 2008 6:54 AM, Daniel Kulp [EMAIL PROTECTED] wrote:
and then tell the ASM folks how to do it properly to avoid it in
the future. We had the same problem when 3.0 was added. All the
perms were messed up and it took several days to get it and all the
mirrors straightened out.
Dan
On Wednesday 23 January 2008, Stephen Connolly wrote:
rsync: opendir /asm/asm/3.1 (in maven2) failed: Permission denied
(13) rsync: opendir /asm/asm-analysis/3.1 (in maven2) failed:
Permission denied (13)
rsync: opendir /asm/asm-commons/3.1 (in maven2) failed: Permission
denied (13) rsync: opendir /asm/asm-tree/3.1 (in maven2) failed:
Permission denied (13) rsync: opendir /asm/asm-xml/3.1 (in maven2)
failed: Permission denied (13) rsync: opendir /asm/asm-all/3.1 (in
maven2) failed: Permission denied (13) rsync: opendir
/asm/asm-util/3.1 (in maven2) failed: Permission denied (13)
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can somebody check the permissions on repo1.maven.org? (groupId asm)
one is for the group asm and another for org.objectweb
On Jan 23, 2008 9:28 AM, Eugene Kuleshov [EMAIL PROTECTED] wrote:
Carlos, why objectweb repo is listed two times in your rsync list?
Xavier, do you know what could be with permissions? I've used regular
deployment over webdav and then flushed shadow copy to the prod site
using OW Forge admin UI.
regards,
Eugene
Carlos Sanchez wrote:
fixed in central
the address to notify of such things is
[EMAIL PROTECTED] or open an issue in jira MEV
And you have the emails of the maintainers in
https://svn.apache.org/repos/asf/maven/archiva/tools/trunk/maven-meeper/src/bin/synchronize/m2-sync/sync.csv
On Jan 23, 2008 6:54 AM, Daniel Kulp [EMAIL PROTECTED] wrote:
and then tell the ASM folks how to do it properly to avoid it in
the future. We had the same problem when 3.0 was added. All the
perms were messed up and it took several days to get it and all the
mirrors straightened out.
Dan
On Wednesday 23 January 2008, Stephen Connolly wrote:
rsync: opendir /asm/asm/3.1 (in maven2) failed: Permission denied
(13) rsync: opendir /asm/asm-analysis/3.1 (in maven2) failed:
Permission denied (13)
rsync: opendir /asm/asm-commons/3.1 (in maven2) failed: Permission
denied (13) rsync: opendir /asm/asm-tree/3.1 (in maven2) failed:
Permission denied (13) rsync: opendir /asm/asm-xml/3.1 (in maven2)
failed: Permission denied (13) rsync: opendir /asm/asm-all/3.1 (in
maven2) failed: Permission denied (13) rsync: opendir
/asm/asm-util/3.1 (in maven2) failed: Permission denied (13)
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: in repo1 it is available
There are discrepancies with version ranges between Maven and OSGi. Not much to do as i don't think anybody will go through all Eclipse plugins and update the poms manually. At least for now you can use exclusions, or force the versions you want in dependencyManagement On Dec 29, 2007 9:48 AM, Felix Knecht [EMAIL PROTECTED] wrote: Carlos Sanchez schrieb: that's right, I still have to polish the eclipse plugin to generate the Eclipse repo using some conventions I tried to build 'my' repo for the eclipse-3.3.1.1 version using maven-eclipse-plugin build from trunk with mvn eclipse:to-maven. All worked well and the artifacts were deployed to were expected. Trying to use them later on I run into the following problem: Couldn't find a version in [3.3.0-v20070606-0010, 3.2.0-v20060605-1400, 3.3.0-v20070531-1300] to match range [3.3.0,4.0.0) org.eclipse:text:jar:null Doing some search about this I found a thread [1] saying that 3.3.0-xxx is less than 3.3.0 (what would explain my problems). Is this an issue of the match range checker or an issue of the pom.xml creation of the eclipse:to-maven goal? Thanks and regards Felix [1] http://www.nabble.com/OverConstrainedVersionException-td14289478s177.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rsync from people.apache.org working?
i just added it anyway On Jan 2, 2008 9:19 PM, Dennis Lundberg [EMAIL PROTECTED] wrote: The ASF M2 repo only syncs org/apache/* and a couple of other directories. The other directories need to be added manually. If you ask on [EMAIL PROTECTED] someone will be able to assist you. Jochen Wiedmann wrote: Hi, I have created http://people.apache.org/repo/m2-ibiblio-rsync-repository/commons-io/commons-io/1.3.2/ yesterday, but the directory 1.3.2 is still missing at http://repo1.maven.org/maven2/commons-io/commons-io/ Anything wrong on my side? Thanks, Jochen -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-osgi 0.2.0
Result 4 +1 (1 not binding) proceeding with the release On Dec 20, 2007 10:32 AM, Lukas Theussl [EMAIL PROTECTED] wrote: +1 -Lukas Carlos Sanchez wrote: ping On Dec 3, 2007 7:05 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: some more votes please ;) On Nov 29, 2007 12:11 AM, Stuart McCulloch [EMAIL PROTECTED] wrote: On 29/11/2007, Carlos Sanchez [EMAIL PROTECTED] wrote: It includes bugfixes in the osgi-maven version conversion Staged in http://people.apache.org/~carlos/staging-repo tested locally: +1 (non-binding) -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Stuart -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-dependency-tree 1.1
Result 4 +1 (1 non binding) pushing to apache repo On Dec 17, 2007 10:07 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Carlos, What's the scoop on this release? Add my +1 to it, I see it's still in your staging repo but isn't out on central yet. I need this to do a dependency plugin release. Thanks, Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Thursday, November 29, 2007 2:14 AM To: Maven Developers List Subject: [VOTE] Release maven-dependency-tree 1.1 It has many improvements related to resolution event handling, using the latest fixes in Maven 2.0.8 Release is staged in http://people.apache.org/~carlos/staging-repo/ -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release maven-osgi 0.2.0
ping On Dec 3, 2007 7:05 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: some more votes please ;) On Nov 29, 2007 12:11 AM, Stuart McCulloch [EMAIL PROTECTED] wrote: On 29/11/2007, Carlos Sanchez [EMAIL PROTECTED] wrote: It includes bugfixes in the osgi-maven version conversion Staged in http://people.apache.org/~carlos/staging-repo tested locally: +1 (non-binding) -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Stuart -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please check/fix permissions in m2-ibiblio-rsync-repository after deploy
there's a fix-permissions.sh in http://people.apache.org/repo/m2-snapshot-repository/ that On Dec 3, 2007 7:13 AM, Daniel Kulp [EMAIL PROTECTED] wrote: I just ran into an issue with the maven-metadata.xml file being non group writable causing the stage plugin to hang (in actuality, it was waiting for the overwrite y/n prompt). stage probably could use the -f option on mv to force it, but. (actually, stage COULD also do a chmod g+w to fix things) In anycase, could everyone that has done a release lately please check the permisions.Especially on the maven-metadata.xml files as that can block anyone else from doing releases in the future. In anycase, doing something like: cd /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/maven chmod -R g+w * would fix any issues. The important ones: maven-shade-plugin/maven-metadata.xml: maven-javadoc-plugin/maven-metadata.xml: maven-invoker-plugin/maven-metadata.xml: maven-clean-plugin/maven-metadata.xml: maven-assembly-plugin/maven-metadata.xml: maven-patch-plugin/maven-metadata.xml: maven-war-plugin/maven-metadata.xml: maven-site-plugin/maven-metadata.xml: Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven-2.1-SNAPSHOT
probably somebody forgot to deploy a snapshot of maven-artifact
On Dec 3, 2007 7:06 AM, Jon SlinnHawkins [EMAIL PROTECTED] wrote:
Is there any reason why i cannot build Maven 2.1 from the trunk
C:\maven-2.1mvn install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Apache Maven
[INFO] Maven Model
[INFO] Maven Profile Model
[INFO] Maven Lifecycle Model
[INFO] Maven Project Builder
[INFO] Maven Plugin API
[INFO] Maven Reporting API
[INFO] Maven Core
[INFO] Maven Embedder
[INFO]
[INFO] Building Apache Maven
[INFO]task-segment: [install]
[INFO]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing C:\maven-2.1\pom.xml to
c:\apps\edevmaven\repository\org\apache\maven\maven\2.1-SNAPSHOT\maven-2.1-SNAPSHOT.pom
[INFO]
[INFO] Building Maven Model
[INFO]task-segment: [install]
[INFO]
[INFO] [modello:java {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-model\target\generated-sources\modello
[INFO] Generating current version: 4.0.0
[INFO] [modello:xpp3-reader {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-model\target\generated-sources\modello
[INFO] Generating current version: 4.0.0
[INFO] [modello:xpp3-writer {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-model\target\generated-sources\modello
[INFO] Generating current version: 4.0.0
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 46 source files to C:\maven-2.1\maven-model\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\maven-2.1\maven-model\target\maven-model-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
C:\maven-2.1\maven-model\target\maven-model-2.1-SNAPSHOT.jar to
c:\apps\edevmaven\repository\org\apache\maven\maven-model\2.1-SNAPSHOT\maven-model-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Maven Profile Model
[INFO]task-segment: [install]
[INFO]
[INFO] [modello:java {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-profile\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-reader {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-profile\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-writer {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-profile\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 15 source files to
C:\maven-2.1\maven-profile\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
C:\maven-2.1\maven-profile\target\maven-profile-2.1-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
C:\maven-2.1\maven-profile\target\maven-profile-2.1-SNAPSHOT.jar to
c:\apps\edevmaven\repository\org\apache\maven\maven-profile\2.1-SNAPSHOT\maven-profile-2.1-SNAPSHOT.jar
[INFO]
[INFO] Building Maven Lifecycle Model
[INFO]task-segment: [install]
[INFO]
[INFO] [modello:java {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-lifecycle\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-reader {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-lifecycle\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [modello:xpp3-writer {execution: standard}]
[INFO] outputDirectory:
C:\maven-2.1\maven-lifecycle\target\generated-sources\modello
[INFO] Generating current version: 1.0.0
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 19 source files to
C:\maven-2.1\maven-lifecycle\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO]
Re: [VOTE] Release maven-osgi 0.2.0
some more votes please ;) On Nov 29, 2007 12:11 AM, Stuart McCulloch [EMAIL PROTECTED] wrote: On 29/11/2007, Carlos Sanchez [EMAIL PROTECTED] wrote: It includes bugfixes in the osgi-maven version conversion Staged in http://people.apache.org/~carlos/staging-repo tested locally: +1 (non-binding) -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Stuart -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
