Le 6 févr. 2013 10:32, "Joachim Durchholz" <j...@durchholz.org> a écrit : > > > Am 30.01.2013 18:14, schrieb Curtis Rueden: > >> If you do not have a server you control, or you think running an MRM is too >> complex, or some other issue, there is install:install-file. Now, I >> absolutely appreciate the concern that it sucks to force all your >> developers to do that on every new local machine. > > > Yup, that's exactly the issue. > > > > But there are ways around >> >> it. One simple way is to commit a bootstrapping script to your SCM that >> automates the entire process: >> - Create the POMs for your non-Mavenized projects (as discussed above in >> point #2). >> - Commit these POMs to your SCM. >> - Write a script that A) downloads the JARs from the external stable >> URLs; and B) calls "mvn install:install-file" with those JARs + >> corresponding POMs. >> - Commit that script to your SCM. > > > Uh... some Windows, some Linux. > No common scripting toolset available. > > That's the main reason why I'm so insistent on making it all actionable from Eclipse: It's a common toolset that I can assume for everyone. > > >> If you are not 100% absolutely sure the external URLs are stable and >> immutable, you can commit the JARs themselves to your SCM instead of >> letting the script download them. (And feel the nostalgia of being back to >> the good ol' days of pure Ant!) > > > Some of that will probably have to happen. > I just found a jar that doesn't even have a stable public SCM :-( > > Still, I want to leverage what can be had. Everything automated is one thing less that needs explaining or fixing up after the inevitable errors have happened. > > >> Regarding Joachim's concern of preserving the metadata: that is one of >> Maven's great strengths. In the POMs you define, you can add all the >> information you want. You can define the developers & contributors to the >> project. You can define the project's web site URL. You can define the SCM >> used. You can define the issue tracker used. The list goes on and on. [1, 2] > > > Yup, that's exactly what I am doing currently. > > >> OK, so after reading all that, you might think it could be nice to have a >> Maven plugin that does what the shell script above would do, given a >> directory full of POMs or something. Then you could bind it to a phase of >> the build and things would "just work" again without developers needing to >> manually bootstrap. So lastly, I agree with Wayne that if you want >> something like that (because you can't run an MRM for some reason), feel >> free to scratch your itch. It would be a valuable addition to the Maven >> ecosystem!
Well, I guess you take what Wayne said out of context. He also said there's a lot of people that don't think this tooling is useful. They'll just install a mrm for the whole company. If you talk about learning curve, it's actually faaaar simpler to just do that and keeping a simple pom to maintain for newbies than having some kind of black magic that they won't find any doc/feedback about in the community since the vast majority of the community just don't do it that complicated way. > > > Heh. I'd love to, but I'm already battling on so many frontiers that I'll have to leave that one to somebody else. > I guess most people simply use the Ant plugin for that kind of task. They use a mrm and a simple settings.xml for the whole company. > The issue I have with Ant is that the project is far too complicated as it is; a newbie who starts Yup, that's the point. > hacking already has to learn Maven, m2e and how it influences Eclipse projects, all the libraries that I'm pulling in; it's a pretty steep learning curve already. I'm trying to cut down on technologies you need to know to start hacking on my project, and Ant looks like it could be avoided. > Maybe I'll have to give in ultimately. But I really want to find out if there's an alternative. Stop resisting ;). There're not. At least there are no *simpler* alternative. That's the point. :) Cheers -- Baptiste
