Re: [M2] Native plugin and multi-platform C++ projects How-To
- Using again the native plugin, create a multi-module project. The parent would contain the C++ source code, while each child module would be devoted to create a single OS/platform specific artifact. I use this option. However you still need to use profile to do debug/release type artifacts I'm not so sure this is going to be as simple as that. C/C++ artifacts are not nearly as nice and tidy as java artifacts. A java artifact is essentially a single file, the .jar file. A C/C++ artifact will be at minimum two files: the library and the header file(s). In addition to that, you will likely need to know the exact compilation options used to compile the code and to link the shared object, so you can match these in your actual project build. The compilation will need to know about your local repository location and set multiple classpath type parameters to point to the right headers and libraries. It would be a great thing to have, but having spent a significant amount of time developing C/C++ build systems, I can guarantee some interesting challenges. I don't think that maven is quite up to it yet, but it is certainly an interesting approach to build avoidance. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Native plugin and multi-platform C++ projects How-To
On 4/13/07, Mark Donszelmann [EMAIL PROTECTED] wrote: Hi Christian, you may have a look at http://java.freehep.org/freehep-nar-plugin it does quite a bit of what you suggest, though it is not perfect. That is pretty neat - but the devil is in the details :) For example, you'd want various variants of the same artifact (debug, optimized, profiled, quantified, instrumented in other ways) ... Not sure AOL cuts it. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profile activation via environment?
ossi petz wrote:
hallo
what is the command line and path you used to fire up maven?
and where did you put these profiles?
The profiles are in my pom.xml file, and the command line is just plain
mvn clean (or any other target), after setting the MAVEN_PROXY_URL
environment variable.,
I expected that the activation section would trigger the profile by
setting the environment variable, but I guess the code that handles
${env.var} is not the same code that handles activations...
--
cg
Christian Goetze schrieb:
Why does this not work?
profile
idproxy/id
activation
property
nameenv.MAVEN_PROXY_URL/name
/property
/activation
repositories
repository
idproxy/id
nameMaven proxy defined by environment/name
url${env.MAVEN_PROXY_URL}/url
/repository
/repositories
pluginRepositories
pluginRepository
idproxy/id
nameMaven proxy defined by environment/name
url${env.MAVEN_PROXY_URL}/url
/pluginRepository
/pluginRepositories
/profile
-
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]
Profile activation via environment?
Why does this not work?
profile
idproxy/id
activation
property
nameenv.MAVEN_PROXY_URL/name
/property
/activation
repositories
repository
idproxy/id
nameMaven proxy defined by environment/name
url${env.MAVEN_PROXY_URL}/url
/repository
/repositories
pluginRepositories
pluginRepository
idproxy/id
nameMaven proxy defined by environment/name
url${env.MAVEN_PROXY_URL}/url
/pluginRepository
/pluginRepositories
/profile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven question
Trouble is that this will not compile the prerequisite projects. You would have to either accept the hit of a full reactor build or use your inside knowledge and cd into all prerequisite subdirs, mvn install those, then build your project. -- cg Thierry Lach wrote: Change your directory to proj1/sub and run maven On 3/9/07, Don Hill [EMAIL PROTECTED] wrote: I am working on a project that has many subprojects, from the root is there a way to compile/install just a targeted subproject. I want to be able to build/install proj1/sub Thanks. root/pom.xml proj1/pom.xml proj1/sub/pom.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MultiModule checkstyle config
I've been trying to reproduce the example setup described in http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html The example doesn't show me the pom.xml file to be used for the build-tools module. I tried making the obvious pom for it with a parent section, I get a cyclic reference error. I tried removing the parent section, but then it fails to actually include the build-tools module in the reactor build and bombs out with a failed to resolve artifact. So, how does it really work ? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is the simplest way to populate a remote depot?
I have some third party jars and want to place them in our common remote repo. I've been placing them there, writing their pom file and doing the sha1sum by hand. Is there some kind of deploy target for this which would make it easier? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the simplest way to populate a remote depot?
Tom Huybrechts wrote: Read That Fine Manual : http://maven.apache.org/plugins/maven-deploy-plugin/file-deployment.html Thanks, sorry Now if someone could tell me how to get the site generation to work... (see other mail) -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-site-plugin not generating proper modules nav menu
I have a project with subprojects, and I wish to generate a site with
some simple reports. It just doesn't work. I always end up with no
module links on the top level index.html page, and if I go to
project-reports.html, all the module links simply point to index.html,
not the actual submodules.
I tried adding my own menu items, but then the leading / of every href
in the items is removed, making the links relative, and useless.
What am I doing wrong? I really don't want to have to write my own site
generations scripts, since the actual content seems to work OK.
--
cg
Here is my src/site/site.xml:
project name=SenSage
bannerLeft
nameSenSage/name
hrefhttp://buildloop.sensage.com/href
srchttp://www.sensage.com/English/Images/Logos/SenSage_logo_182px.gif/src
/bannerLeft
bannerRight
nameSenSage/name
/bannerRight
body
${modules}
${reports}
/body
/project
Here is my reporting section from the top level pom.xml
reporting
outputDirectory${DO}/target/site/outputDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
reportSets
reportSet
reports
reportdependencies/report
/reports
/reportSet
/reportSets
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
aggregatetrue/aggregate
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
configuration
aggregatetrue/aggregate
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
aggregatetrue/aggregate
configLocationcheckstyle.xml/configLocation
/configuration
/plugin
/plugins
/reporting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I deactivate an activeProfile?
franz see wrote: Good day to you, CG, AFAIK, there's none. If you want, you can remove your profile from the activeProfiles section, and add to your profile something like this ... activation property name!exclude-this-profile/name /property /activation ... I tried profile activation - it doesn't seem to work. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I deactivate an activeProfile?
franz see wrote: Good day to you, CG, May I ask for a snippet of your settings where you used the activation, the maven command you used ( i.e. mvn install ), and what made you say that it did not work? :) Those info would help in determining why it did not work :) Ok. Here's what I tried to do: properties tunneltrue/tunnel /properties ... profiles profile idtunnel/id activation property nametunnel/name valuetrue/value /property /activation ... /profile /profiles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I deactivate an activeProfile?
franz see wrote: Good day to you, CG, May I ask for a snippet of your settings where you used the activation, the maven command you used ( i.e. mvn install ), and what made you say that it did not work? :) Those info would help in determining why it did not work :) The negative activation works. Thanks. I guess you just can't activate a profile with properties defined in the pom itself. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I deactivate an activeProfile?
Is there a magic incantation on the command line to deactivate a profile mentioned in the activeProfiles / section? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependencies are bloated in M2
Tandon, Pankaj wrote: So the questions are: 1. How can we control what get's into WEB-INF/lib. We tried all the scopes mentioned, but that did not help. I believe that the scope that should work is provided. The problem is that I don't know if maven is smart enough to remove a provided dependency from the transitive closure. I would call that a bug if it didn't. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compile tries to bundle up the ear - should it?
EJ Ciramella wrote: Still haven't seen any response - this has us wedged, can anyone shed any light on this for me? If you run mvn anything in some project/module subdirectory, you are assuming that all dependencies are built and installed, and therefore available either from your local repo, or from your other repositories. If this is not true, then you cannot build. If you are in the situation where your code builds, but some else's code doesn't, then you won't be able to use your .ear file anyway. If you don't need the .ear file yet, but do wish to run unit tests on your code, then maybe you should temparily change your packaging to jar. If you want a more permanent solution, then make a separate artifact which just has the dependencies to pack the ear, but no code (except perhaps for some simple wrapping or debugging code) on its own... But to me it sounds simply as if you'd want to run mvn from a higher directory to get it to build all of your modules - or that you need to ensure that the other people deploy the results of their builds. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven newbie questions
Ok, lemme see if I can do this one - being a newbie myself :) srinivas ramgopal wrote: Hi all, I am new to Maven. 1) What is the purpose of remote repository (other than ibilbilo) To store stuff not in ibiblio - for example your own stuff 2) Whenever a file is modified in a maven project how is the SNAPSHOT jar updated in the remote repository? Using mvn deploy, after inserting proper distributionManagement/ section into your pom 3) Are there two different ways to adding a dependency jar and a project artifact jar to the remote repository? Not sure I understand that one. 4) Is maven 'deploy' goal and actualy copying of a dependency or artifact jar to remote repository same? Yes, I guess... artifact != jar. an artifact can be anything, but will include at least a pom. What the artifact will be depends on your packaging/ setting. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] scope to include an internal dependency into a war artifact
Roberto UserList wrote:
Hi all! How can I configure scope tag, in order to, package one of the my
project's dependency artifact into the war artifact of my project?
Check it out! I'd like to include artifact comp.jar into the war
artifact.
I've tried compile and provided, but both of them did not work.
dependency
groupIdvariglog/groupId
artifactIdmodellib/artifactId
version${versao.sis}/version
scopeprovided/scope^
/dependency
/dependencies
Thanks in advance for the help.
Try leaving out the scope altogether. provided means explicitly that
you do not want it included, since it is provided by the environment,
and compile means it is only relevant for that phase.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi step build process for multi module project
Paul Edwards wrote: Hi, When running a M2 build over a set of modules within a profile within a parent project, is it possible to cause certain plugin goals to run only once while others run on each sub-project defined in the profile? What I am attempting to accomplish goes like this: Step 1: cargo:stop Step 2: module 1 clean package cargo:deploy Step 3: module 2 clean package cargo:deploy Step 4: module 3 clean package cargo:deploy Step 5: cargo:start What I am able to accomplish if I run the following: mvn cargo:stop clean package cargo:deploy cargo:start is the following sequence: Step 1: cargo:stop module 1 clean package cargo:deploy cargo:start Step 2: cargo:stop module 2 clean package cargo:deploy cargo:start Step 3: cargo:stop module 3 clean package cargo:deploy cargo:start Step 4: cargo:stop module 4 clean package cargo:deploy cargo:start As you can imaging, all that starting and stopping of the web server is not only time consuming but tends to cause Windows to chuck a wanger. I have attempted to bind cargo:stop and cargo:start to lifecycle phases but the same phases iterate for each sub-project... no good. Any ideas? Maybe making a module stop and start, with packaging pom, with the appropriate plugin config entries for stopping and starting, then make start depend on all other modules, and make all of those other modules depend on stop. Then, the reactor build order will be as you desired. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is concurrent execution of two Mavens safe?
Štěpán Roh wrote: Hello. What I would like to know is whether if I run two Mavens at once and they both change something in local repository at the same time (either downloading required plugin or doing an install) if it is possible that the repository can be damaged (downloaded plugin is incomplete, something is not installed or metadata are wrong). Thank you for your anwsers. Please CC me, because I am not subscribed. No. I wished it was, but it isn't. The only way you can run concurrent mavens is by ensuring that every instance uses its own local repo. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiple parallel instances of maven using the same local repo...
... doesn't work, as I expected. Is there any hope that a JIRA request for enabling a locking mechanism for the local repo to allow multiple instances of maven to run has a chance of getting implemented? Are there any plans to make maven itself multithreaded or capable of parallel builds? I guess I can make my parallel maven instances point to their own repos and just live with the needless duplication of disk usage and network traffic. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 (and plugins) need to be released frequently to make maven interesting
Eric Brown wrote: There is no shortage of numbers in the world. What is the problem with releasing often? So what if a bug occasionally gets its way into a release -- you can always specify an older version of a plugin that didn't have some new bug. True, a lot of plugins are under 3rd party control and not part of the core maven. But if the core maven team starts releasing more often and understands why releases are important, many of the 3rd parties will follow suit. Right now maven seems more like a toy and is constantly frustrating when trying to use it on a real project (due largely to known bugs many of which have been fixed in SNAPSHOTs for over 6-months now and/ or several plugins that have produced SNAPSHOT builds but no released version). I would like to second the motion... Over here, I'm constantly teetering on the edge of dropping maven altogether. I really really want to like it, but it is a hard sell to developers, especially if they have to end up writing ant tasks after all... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How far away is maven-assembly-plugin-2.2 from being released?
Just wanted to know whether it is worthwhile for me to replace my maven-proxy with something that understands all aspects of snapshot management... I'd rather use released code if possible... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jar plugin and assembly plugin disagree on SNAPSHOT versions
So I have my jar plugin include the classpath in the manifest. That classpath specifies the version text as x.y-SNAPSHOT. The assembly plugin, on the other hand, packs the resolved snapshot name (x.y-date.sig-buildnr) of the jars into the assembly, causing the application to fail. Is there a way to tell the assembly plugin to not do that? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jsmooth anyone?
We're struggling with getting that to work... and I was wondering if anyone had some working code to contribute :) Ciurrently, we're trying to hook in an ant task to do this. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar plugin and assembly plugin disagree on SNAPSHOT versions
John Casey wrote: If you use the 2.2-SNAPSHOT version of the assembly plugin, you can specify the outputFileNameMapping in the dependencySet to be something like the following descriptor has: Stupid question: what is the groupId of the 2.2-SNAPSHOT version of the assembly plugin? It doesn't seem to be org.apache.maven.plugins. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar plugin and assembly plugin disagree on SNAPSHOT versions
Christian Goetze wrote: John Casey wrote: If you use the 2.2-SNAPSHOT version of the assembly plugin, you can specify the outputFileNameMapping in the dependencySet to be something like the following descriptor has: Stupid question: what is the groupId of the 2.2-SNAPSHOT version of the assembly plugin? It doesn't seem to be org.apache.maven.plugins. Because they are in a different repo... duh :) -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar plugin and assembly plugin disagree on SNAPSHOT versions
John Casey wrote: you'll need the following: pluginRepositories pluginRepository idapache.snapshots/id urlhttp://people.apache.org/repo/m2-snapshot-repository/url /pluginRepository /pluginRepositories Note that this repository has NOT disabled releases...this is important because of a bug in Maven = 2.0.4, where plugin-version resolution will only check repositories with releases enabled. It should work for you with this repository in place. Thanks ... Now my problem is that maven-proxy doesn't seem to understand how to resolve SNAPSHOT names, it is actually looking for x.y-SNAPSHOT. I heard that maven-proxy is obsolete - so what are people using for proxy instead? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Just checking my understanding of SNAPSHOT vs real versions
A real version is only downloaded into your local repo if it isn't already there. A SNAPSHOT version is always checked against central (or other outside repos) to see if there is a newer version available. Is that correct? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just checking my understanding of SNAPSHOT vs real versions
Patrick Schneider wrote: Snapshots are checked once a day by default. You can override this by passing the -U flag, forcing maven to update its snapshots. Here's a good review of snaps, by Brett: http://blogs.maven.org/brett/2005/04/15/1113510156000.html Thanks - so it would seem that snapshot-policy isn't implemented yet - or that I don't know where to set it... otoh, once a day isn't too bad. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jar signing - the good and the bad
diroussel wrote: The question is, why is surefire not using the un-signed jar. I have two jars: target\MyJar.jar target\signed\MyJar.jar so why is surefire choosing the second one, not the normal one in the normal place. Any ideas? No ideas here, sorry Just wanted to add my opinion that the jar signing should really be in the assembly plugin. It is not very useful to have it in the jar plugin, since all the third party jars which get pulled in via transitive dependencies won't get signed. Currently, I do the jar signing as a post-processing step outside of maven, for that reason. A pity, if you ask me... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I make assembly include test jars?
As subject says ... it would seem that the assembly descriptors assume you're packaging main. Am I supposed to use full paths in the assembly descriptor? Anyone have an example? Thanks in advance! -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
First impressions of using maven (long)
In this post, I'd like to summarize my first impressions of using maven. The product built in my company is a mixed bag of C/C++ code, java code and perl code. It is a classic three tier app, with the back end written in C/C++, the middle tier written in perl and java and the GUI written in java. The java code is built via ant scripts, and they have grown to be quite intricate and unwieldy, and they also tended to obscure the actual dependencies between artifacts, causing multiple jars to contain varying subsets of the class files, and various random jars being duplicated into several places in the source tree -- in other words: your classic organically grown mess. Also, the way the ant scripts were written made it very hard to get incremental parallel builds to work, since they tended to spill files all over the tree while invoking each others in scary ways. The top level build system is written in a make clone called cook, written by a nice guy in Australia, Peter Miller. This clone has a variety of extras not available in any other build tool, which made it possible for me to write a system implementing a philosophy that matches almost perfectly with maven's philosophy. See http://www.cg-soft.com/tools/build/ for details. One thing to note is that cook is fairly old software (I think that the first version came out over 20 years ago), which makes the absence of many of its features in newer systems that much more depressing - more on that later. So maven seems like a perfect fit, especially since our java code is fairly vanilla, using standard technologies and very few hacks. Indeed, it was possible for me to convert about 60% of the java build to maven builds within 2 days after reading the Better Builds with Maven book. Needless to say, I was impressed. I really want to like maven. I think it has the right ideas, and the way it deals with deploying and reusing artifacts built elsewhere is a great model for dealing with third party software, and even inhouse software build by separate teams. It effortlessly implements a wink-in scheme which usually requires a lot of effort to get to work. In particular, I like the fact that developers only need to have those subtrees checked out where they are actually making changes, and can still build the complete product by downloading the artifacts built and deployed by the continuous build loop. I am in the process of integrating some of the maven ideas (mainly the plugin architecture) into my cook based build system, and I almost wished maven had some support for C/C++ style artifacts - but I realize that this is a much harder problem than java artifacts - a testament to the wisdom of the java designers. Nevertheless, there are difficulties and disappointments: * Incremental builds are not reliable; * Builds are not reproducible; * Builds are not parallizable and distributable; * Reactor builds are all or nothing; * Propagation of build parameters is undocumented and unpredictable; * Release process is bizarre. I think these are important issues. I'll go into details later, but I cannot stress how important it is to have a reliable build tool that actually removes workload from developers. Most developers are not thrilled about having control taken away from them via an opiniated tool like maven. They will only go along if it provides tangible benefits. It is therefore -extremely-important- to not disappoint them. I don't think there is disagreement about that - after all, the idea plugin is a great step in the right direction, but I do fear that people do not fully appreciate the difficulties created by having a build tool that fails in mysterious and random, hard to debug ways. Developers have strong egos, and will go to great lengths to try to figure out things by themselves and will only come and ask questions when they are desperate - and then they will blame the tool and the people who brought it into their lives. Now, in detail: _Incremental Builds are not Reliable_ There are two well known failure modes: * A source file has been relocated or removed * A source file was updated, but with a timestamp older than the associated derived file(s). Supporting those two cases is not really that hard: In the first case, you record a hash signature of the sorted list of all ingredient files used to produce the target file, and consider it out of date if that signature changes. In the second case, you record timestamp and hash signature of the source file and consider it out of date if the timestamp and signature changes. As a side effect, you get free build avoidance by comparing hash signature of a generated file with the previous version and consider subsequent dependencies up to date if the signature did not change. cook has been doing this for years and it works great. The real problem seems to be a lack of awareness of why this is so bad. The classic
Re: How can I make assembly include test jars?
Thanks for the tips. I ended up making it its own module and just use the standard assembly. My thinking is that if it's being distributed, it isn't really a test anymore. I hope this conforms with the idea of the test vs main source subtrees... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
Wayne Fay wrote: Or would you expect the mirror java.net to Central process to alter all the pom files and remove the java.net repo references? I think that they should not contain explicit location references at all, relying instead on the locations defined in the poms traversed previously in your transitive dependency search. I also think that the maven proxy solution should be advocated, if not required, and that the maven proxy should be an integral part of maven, not something fabricated by third parties. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: External repositories listed in centrally deployed poms?
Just would like to add my agreement with Mykel's position. The problem is that you can have the best developers in your world, and still get screwed by one guy outside accidentally including a dependency with encumbering licensing. That's the big drawback of the automatic inclusion of transitive dependencies. I am very lucky to be in an environment where I actually can download anything fron anywhere, but I still remain uncomfortable with this aspect of maven. For one, I need to trust the community that it won't change anything down the road, and furthermore I need to keep snapshots of the repository image for reliable build reproduction purposes. I believe running maven without at least some proxy setup is asking for trouble, even in the most liberal environment. -- cg Mykel Alvis wrote: I still maintain, as I have said in other threads, you should audit not enforce lock down. Why is that? It doesn't seem a particularly valid method in my current environment, but I'm willing to listen. I think my developers are competent for the most part, given that they're a fairly large group broken into several pieces. But essentially to a (gender-nonspecific pronoun) they are not competent with maven, build processes in general or the reasons behind the controls associated with those processes. I disagree about the lockdown vs. audit question, but I don't completely disagree...except when I'm obligated to do otherwise by the terms of my employment. Like at each commercial environment that I've worked in for the last several years. I think audits usually work to handle dependency issues, and recommended them prior to release. But my current working dependency set is now over 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of times before I got here an artifact slipped through the audit cracks so caching proxies are the only choice that I can see. I'm charged with working on an accepted asset list that would scan checked in poms and report checkins that had dependencies not on the list, but that's a few steps down the to-do list. I should also note that there was no instance of distribution of disallowed artifacts at previous employers, but they had identical policies. IANAL, but I do try to keep up with the legalities associated with licensing and if you're a largish firm that sells software and somebody catches on that you've distributed something unacceptably then it's your buttocks in the fire. That fire would also, very likely, include the firing of me. :) As for locking down what can and can't be downloaded, it's a moot point. Even while I've been mandated to restrict maven's use of external repos, I can't help but do it since maven can't actually reach external repos from any build host that isn't part of the domain (which includes my entire build farm). :( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: idea plugin question
Roald Bankras wrote: First time I just run the idea:idea goal. After setting op my workspace in intellij, I only run idea:module to update the dependencies. Thanks, yes, that seems to be the way to go - now I need to find out if the maven plugin for IDEA has a way to set this up to happen automatically on startup or on demand. The goal for me is to create an IDEA config which will bootstrap maven and do the right thing without developers needing to do more than get the source tree and install IDEA. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: idea plugin question
Sorry for the repost, but I can't believe that nobody is having this problem. What do you guys do? Christian Goetze wrote: How can I merge custom idea settings (e.g. the arguments to the idea run targets, perforce settings etc) into the idea project files generated via maven? On the one hand, I would like to get the benefit of the source and javadoc download and the dependency knowledge maven provides, but on the other hand I cannot ask developers to constantly clobber their project files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to sign all jars included in an assembly?
franz see wrote: Good day to you, Christian, You can sign your jars using jar:sign ( see [1] ). However, it needs you to input the location and filename. Yes, I can do that, but that was not what I was asking. The problem I have is that I want to sign all the third party jars imported via the transitive dependencies. It would seem that the assembly plugin would be the ideal candidate for the job of doing the signing, but I guess I'm missing something... It's not a vital problem for me, since I repack the stuff into rpms anyway and can do the signing there, but it would be nice if maven could do it... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: accessing sources of third party jars
Edwin Punzalan wrote: If the artifacts have sources and javadocs deployed with them, then using -DdownloadSources=true and -DdownloadJavadocs=true is what you need. The plugin will download them and attach them to the project to help you in your development. Hope that helps ^_^ Ok, and how are they deployed into the repo? What is the expected format/naming/location? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
idea plugin question
How can I merge custom idea settings (e.g. the arguments to the idea run targets, perforce settings etc) into the idea project files generated via maven? On the one hand, I would like to get the benefit of the source and javadoc download and the dependency knowledge maven provides, but on the other hand I cannot ask developers to constantly clobber their project files. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: accessing sources of third party jars
Christian Goetze wrote: Edwin Punzalan wrote: If the artifacts have sources and javadocs deployed with them, then using -DdownloadSources=true and -DdownloadJavadocs=true is what you need. The plugin will download them and attach them to the project to help you in your development. Hope that helps ^_^ Ok, and how are they deployed into the repo? What is the expected format/naming/location? -- cg Answered the question myself: xyz-1.2.3-sources.jar and xyz-1.2.3-javadoc.jar -sigh- plural/singular mixup Now, for the next trick: how can I cause these to be downloaded without regenerating the project files? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
accessing sources of third party jars
This is not clear for me from the maven book. We have some third party jars that come with source code and javadocs, and I'd like those to be retrieved via a maven build. How can I do that? Do I actually need to make these into full-blown modules or is there a way to just handle the zip files directly, since idea is able to look at zip files for sources and javadocs... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to sign all jars included in an assembly?
I'd like to configure the assembly plugin to sign all jars pulled in by the transitive dependency resolution. How can I accomplish that? Otherwise I would need to hand-sign all the thirdparty jars in my repository... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiple non-recursive mvn invocations running in parallel?
Will multiple non-recursive mvn -N install invocations running in parallel, each building and installing a different artifact, interact with each other in some way? My naive assumption is that they shouldn't, since they will populate different parts of the local repository, and since I'm not deploying... Anything I'm missing? would be a pitty to force single threaded execution there... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to invoke mvn to not do the reactor build?
Is there an option to disable the reactor build when invoking maven from the project parent? All I want is the installed pom, nothing else. Background: I need to embed maven into a larger build system, and I would like to be more specific about which parts of a project need rebuilding. My plan is therefore to generate dependencies from the pom.xml files and to have my build system invoke maven directly in the module subdirs. The subdir builds require that the parent pom.xml be installed. I can live with that as long as that is the only thing that happens. The reason I wish to be specific is to support incremental product builds and tests. I don't want every change to the java source to trigger all java related rebuilds, packings, installs and test runs, but only the ones specifically including the derived objects generated by the change. As it turns out, it is probably not a big deal if there is no way to disable the reactor build, since the parent pom.xml will only be out of date when it changes, in which case everything needs to be rebuilt anyway. The only issue is that in my scenario, maven will end up scanning every module tree at least twice... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven proxy question
Barrie Treloar wrote: Can you paste in the types of build failures you are getting? I get the usual cannot find artifact, can you upload it with the following commands error. I changed the the proxy setting to not check for pom file updates, and I'll see if it happens again. Proxy log shows: 2006-12-07 08:58:45,707 [ERROR] proxy.config.RepoConfiguration - Repo[www-ibiblio-org]: Failure getting meta information for /org/apache/apache/1/apache-1.pom java.lang.RuntimeException: java.net.ConnectException: Connection timed out 2006-12-07 08:58:45,708 [INFO ] components.impl.DefaultSnapshotCache - Updating /org/apache/apache/1/apache-1.pom in snapshot cache 2006-12-07 08:58:45,708 [ERROR] proxy.engine.DownloadEngine - org.apache.maven.proxy.engine.RepoAccessException: java.net.ConnectException: C onnection timed out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven proxy question
I am using the maven proxy as described in http://docs.codehaus.org/display/MAVENUSER/Using+Maven+in+a+corporate+environment, but I am observing spurious build failures due to some of the actual remote sites not always responding in a timely manner. Is there a way to configure maven proxy to not fail, but to simply send the cached version instead? Should I just set the cache timeout to some really large value? What I would like, though, is that it does try to get an update, but not fail if the update fails? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: module builds but doesn't install
Jörg Schaible wrote: Christian Goetze wrote on Tuesday, December 05, 2006 10:49 PM: I have a situation where a module with packaging jar builds, i.e. it produces a .jar file, but it doesn't install if maven is run from the parent project directory. No indication by mvn why. It will install if I run maven from the module directory. Any ideas how I can debug this? Do you use by chance in another project an assembly? It might destroy the lifecycle ... http://jira.codehaus.org/browse/MASSEMBLY-97 (note, 2.2 is not released yet). Yep, I found that out by removing all modules and adding them back one by one. Those with assemblies cause the subsequent build lifecycle to fail. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I need help with multi-module project site generation.
Wendy Smoak wrote:
On 12/5/06, Christian Goetze [EMAIL PROTECTED] wrote:
If I generate the default site according to the mergere book, I get
essentially a useless cover page with a navigation menu that lists the
modules, but without links
I've seen that happen too. Most of my projects have a custom site.xml
and aren't using ${modules} (?) though, so I've never tried to chase
it down. Can you reproduce it with a simple parent-and-two-children
multi-module project?
I'll see what I can do, thanks for the pointers, and at least I feel
less alone now :)
mvn site fails with an internal error, stumbling over a dependency
which seems to stem from the java code being javadoc'ed itself.
Are you using dependencyManagement ? This sounds familiar, but I
thought it was fixed. First try 'mvn site -U' to make sure you've got
the latest plugin versions, or (better) add a version element to set
the version you want to use.
Yes, I do use dependencyManagement. I tried mvn site -U and it still
fails. So I can't use dependencyManagement? That would suck...
Not sure what you mean here... 'mvn site' is only going to generate
the pieces of a multi-module site under the various 'target'
directories. To see what the whole thing looks like you'll need to
use either site:stage or site:deploy.
The default index.html page will include the description from the
pom, if you want more than that, add src/site/apt/index.apt with your
content.
Yes, I am slowly discovering that the deploy part of the lifecycle is
essential, for other stuff too...
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I need help with multi-module project site generation.
Wendy Smoak wrote: which seems to stem from the java code being javadoc'ed itself. mvn site fails with an internal error, stumbling over a dependency Are you using dependencyManagement ? This sounds familiar, but I thought it was fixed. First try 'mvn site -U' to make sure you've got the latest plugin versions, or (better) add a version element to set the version you want to use. I put version elements to all my dependencies, but it still fails with: Embedded error: Error rendering Maven report: Exit code: 1 - /local/home/cg/a/main/src/java/common/src/main/java/com/sensage/util/EmailUtil.java:4: package javax.mail.internet does not exist import javax.mail.internet.InternetAddress; (same failure as before) I also tried adding the dependencies to the build/plugins/plugin/dependencies section -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I need help with multi-module project site generation.
Wayne Fay wrote: Probably a silly question, but you added a dependency on javax.mail, right? And unless I'm mistaken, this is a Jar you have to download from Sun and add to your local repo manually. I did all that, yes... Thanks :) After all, my project builds fine, it's just the aggregating javadoc plugin that fails. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Projects with empty modules
Maybe a JIRA issue... I've been setting up a project framework with no code in the modules yet, but with dependencies, and I notice that running mvn from the top causes the empty module to be skipped and subsequent dependency failures, but running mvn from within the empty project will cause an empty jar file to be created, available for dependency resolution in a subsequent build from the top. Obviously, the solution is to put at least one stub class into every module, but I do wonder why the reactor build behaves differently than the module build... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Merging vs Overriding Settings?
I'm not clear on the algorithm used for inheritance of pom settings. It would seem that some settings are merged (obvious example: dependencies), whereas others seem to override. Is there any consistent rule about this or is it just whatever was deemed appropriate by whomever writing that section? For example, I would like to be able to do this, but it doesn't seem to work: In the parent pom.xml: .. build !-- Always exclude this file -- resources resource excludes exclude**/.cook.fp/exclude /excludes /resource /resources In the module pom.xml: build !-- Cause resource filtering -- resources resource directorysrc/main/assembly/directory filteringtrue/filtering /resource /resources And I would like to end up with the effective pom of: build !-- Cause resource filtering -- resources resource directorysrc/main/assembly/directory filteringtrue/filtering excludes exclude**/.cook.fp/exclude /excludes /resource /resources but I don't, instead the module setting replaces the parent setting. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Projects with empty modules
Christian Goetze wrote: Maybe a JIRA issue... I've been setting up a project framework with no code in the modules yet, but with dependencies, and I notice that running mvn from the top causes the empty module to be skipped and subsequent dependency failures, but running mvn from within the empty project will cause an empty jar file to be created, available for dependency resolution in a subsequent build from the top. Obviously, the solution is to put at least one stub class into every module, but I do wonder why the reactor build behaves differently than the module build... Well, turns out that doesn't fix the problem. Something is causing it to not install. How would I go about debugging this? mvn -e doesn't say anything useful... I see it actually building the jar, but for some reason it isn't installing it... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
module builds but doesn't install
I have a situation where a module with packaging jar builds, i.e. it produces a .jar file, but it doesn't install if maven is run from the parent project directory. No indication by mvn why. It will install if I run maven from the module directory. Any ideas how I can debug this? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Workaround: module builds but doesn't install
Christian Goetze wrote: I have a situation where a module with packaging jar builds, i.e. it produces a .jar file, but it doesn't install if maven is run from the parent project directory. No indication by mvn why. It will install if I run maven from the module directory. By removing all modules and adding them back in one by one, I discovered that as soon as I add in a module with an assembly, subsequently built modules do not get installed. This looks like a bug to me. My workaround is to add dummy dependencies with scopeprovided/scope to force the reactor to execute builds in an order where the modules with assemblies are built last. This will of course only work as long as the modules with the assemblies remain leaves in the dependency tree... Comments? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I need help with multi-module project site generation.
So I have a multi-module project and I would like to generate a site which includes javadoc and jxr. What am I supposed to do? I would be extremelty grateful to anyone who can provide an example which has a shot at working... If I generate the default site according to the mergere book, I get essentially a useless cover page with a navigation menu that lists the modules, but without links If in the parent pom.xml, I say: reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration aggregatetrue/aggregate /configuration /plugin mvn site fails with an internal error, stumbling over a dependency which seems to stem from the java code being javadoc'ed itself. If I set it to false, I don't see any link or anything at all. Is the intent to let maven generate some of the pages, and I need to add the static pages linking them all together myself? I cannot stress enough how frustrating it is the wade through the many twisty XML hierarchies -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to run checkstyle earlier in the build lifecycle?
I know it runs as part of mvn site, but some people wish to see it run earlier, say as part of install, or even test. How do I do that? -- cg P.S. I'm still struggling with multi-module project site generation. I just can't get the navigation links to work. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to ignore certain files in the source tree
Sorry if this is another FAQ, but I can't find an easy answer... I would like to systematically ignore certain source files in the build. I don;t want them to appear in my jars or any other artifacts. Is there a global way to exclude them? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to ignore certain files in the source tree
Wendy Smoak wrote: On 12/4/06, Christian Goetze [EMAIL PROTECTED] wrote: I would like to systematically ignore certain source files in the build. I don;t want them to appear in my jars or any other artifacts. Is there a global way to exclude them? Where are the files located, and what type of files are they? They are . files generated by the build system into which I'm embedding maven. They contain additional metadata about the files and I do not have the option of moving them around. They will appear wherever source files exist, and they seem to end up in the jars generated by the packaging. If they are under src/main/resources, you can use resourceexcludes to ignore them. http://maven.apache.org/ref/2.0.4/maven-model/maven.html I'm wondering if there isn't an option for the maven-jar-plugin, but I can't seem to find any. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to ignore certain files in the source tree
Wendy Smoak wrote: On 12/4/06, Christian Goetze [EMAIL PROTECTED] wrote: Where are the files located, and what type of files are they? They are . files generated by the build system into which I'm embedding maven. They contain additional metadata about the files and I do not have the option of moving them around. They will appear wherever source files exist, and they seem to end up in the jars generated by the packaging. If they are under src/main/java, it's odd that they're getting included. IME only .java files from there get compiled, everything else is ignored. (For example, if you have .properties files stored with your source code, you have to add a resource to pick them up.) You're right - the file ended up included via a filtered resource, and my exclude didn't immediately do the job because I didn't say mvn clean... ... which leads me to another gripe about maven, namely that incremental builds are not very robust ... but I know quite well that this is a very hard problem (hence the metadata files of the embedding build system etc... ) -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using ant and alternative local repositories with Maven
If we were not using the Maven ant tasks, there are several ways to address this matter. There is the -s parameter to Maven, there is the $M2_HOME/conf/settings.xml, where we could vary the value of $M2_HOME according to which build we are doing. These mechanisms do not work for the Maven ant tasks, as those tasks ignore $M2_HOME/conf and have no access to a -s argument. Can anyone suggest what to do? Someone here suggested filing a JIRA request for enhancement to Maven Antlib. That will take quite awhile, so I'm hoping there actually is already a way to do this and I just haven't found it yet. The way I solve the repository problem is to generate a settings.xml file to my taste, then invoke maven with -Dorg.apache.maven.global-settings=path-to-my-settings.xml-file -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
It could be told by setting -Dmy_version=version and using
${my_version} in the parent reference. But not even that works.
You're missing the point. A child pom MUST be able to know what
version its
parent is BEFORE it can inherit anything. Wayne is right... it's
strickly a
chicken-and-egg problem. Its a very bad design to create a project that
requires a parameter from the command-line to decifer its actualy
coordinates... you'd have to type in the version EVERY TIME you used
it. So
rather than:
mvn install
You users must enter:
mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT
You're not really gaining anything here.
Yes you are, because you can modify what mvn is and add it to the
wrapper script. You can then use whatever method pleases you to
determine the current version number.
The main point here is that one would like to have -exactly- -one- place
where version numbers are defined and changed. Forcing people to
manually edit dozens of pom.xml files every time the version number
changes is just bad design.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
Wendy Smoak wrote: On 11/22/06, Christian Goetze [EMAIL PROTECTED] wrote: The main point here is that one would like to have -exactly- -one- place where version numbers are defined and changed. Forcing people to manually edit dozens of pom.xml files every time the version number changes is just bad design. The intent is for you to use the release plugin, and for Maven to update these version numbers during the release process. http://maven.apache.org/plugins/maven-release-plugin/introduction.html Trouble with that is that it assumes that our release process maps to the assumptions made in the plugin. I actually don't have too much of a beef with it, but it does not address some of the issues that arise in the non-java world, and it requires that you keep state externally. I guess my one line criticism is that the release plugin assumes you know ahead of time that you are going to release this exact upcoming build. Granted, I'm still a maven newbie and I accept the fact that I may understand all of the design decisions - so be patient with me please :) -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Maven does several things... one of which is building, but the other is to gently (OK, maybe not THAT gently) push users to adhere to standards. It is not by accident that non-standard behaviors are untenable. The standard in this situation you describe is to use the maven-release-plugin. I know, I know... doco sucks - we're working on it. See below - I think the design of the release plugin is inadequate Before you think this this is an isolated weakness on the part of Maven, note that this kind of push is happening all over, and once you learn the standard you see how nice it is to be able to go to any project built with Maven and be able to use and navigate through it. This is a similar thought behind Ruby on Rails, and clones like Trax... convention over configuration. I understand that - those are the reasons I chose maven to begin with. In fact, for the past 9 years I've been developing build systems designed on that exact premise, except that I haven't really pushed it out onto people outside my organisation (see http://www.cg-soft.com/tools/build/, even if it's somewhat dated by now, I still use that system) Nevertheless, it only works if the convention is useful and correct. If the convention is flawed, then you need a way to fix it or work around it. For now, I'm working around it by simply not using it. Someday, I hope I can start using it, because the stuff I'm doing now isn't so hot. Users shouldn't HAVE to know that in your super-special build system, they have to type mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT to use it. There are ways around that particular issue (for example, placing that -D into the wrapper script which invokes maven), but those are besides the point. Here is what I do not like about the process implied by the release plugin. Perhaps I'm not understanding all aspects of it, and perhaps I'm just smoking dope, but here's what I see: In order to use the release plugin, I have to decide to go for it, and call a particular source tree releasable. This may sound trivial, but it isn't. How do I decide that? Say I have a QA department, and they tell me: looking good, so I release. I go through the motions, but now I need to have faith that the actual release build is going to be exactly equivalent to the builds QA used to say looking good. Trouble is: we're not a faith based organization. I need to -prove- that it -is- the same - AND I need to prove it not just to my satisfaction, but to the satisfaction of any pointy-haired boss that feels the need for some hands-on auditing. That is actually very hard to do in real life projects. The simple fact of removing the -SNAPSHOT from version numbers may have all sorts of side effects - if only by removing any hope of doing binary checksums of the build products - something you can't really do anyway, since way too many processes insert useless timestamp info all over the place. The only way I know of doing this is to produce release candidates that look exactly as if they were the actual release, and keep building new ones until QA says it's good. They then use that exact build. Essentially, manage releases by access control, not by naming. So I guess the solution is to continually run the release plugin to generate various new versions with new build numbers, feeding a constant stream of release candidates to QA. And that's where I hit the second snag, which may be easy to fix, but it isn't clear at all from the documentation. The release plugin needs to work non-interactively - otherwise I'd be sitting there doing nothing else but maven builds. The third snag is that I need to have a way to explain it how to use perforce, and in a way that matches the way we are using perforce in this shop. I guess I can live with the constant automatic checkouts and checkins of pom.xml files, but I'm not sure how this affects developers... Finally, I need to integrate maven into a larger system - until the day comes when maven knows -everything- about -everything-, simply working on the premise that maven is the ultimate controller is not helpful. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Wendy Smoak wrote: On 11/22/06, Christian Goetze [EMAIL PROTECTED] wrote: In order to use the release plugin, I have to decide to go for it, and call a particular source tree releasable. This may sound trivial, but it isn't. How do I decide that? We've been struggling with the same issue inside Apache, where our policies require a vote on the actual artifacts that will be released. I haven't seen anything recently, but last month we had a discussion about changing the release process to include a staging or proposal phase. So it would be release:prepare, release:propose, then either release:accept or release:clean In between propose and accept is when your QA department would do their work... and if accepted, the exact artifacts they've tested will be promoted to the release repository. This is I think where the problem is: if the promotion involves a rebuild, especially one where the source code changes - even if it's only the version string, then you have created uncertainty and devalued the testing effort of QA. That's why I want every build to be done as if it was a release, and only call something a release by granting access to it. This design principle is fundamental in the build system into which I'm attempting to embed maven - hence my problem :) Here's the thread: Thanks for the link. I'll read it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
Wayne Fay wrote:
Its a chicken and egg problem.
If you don't hard-code parent version in child = which parent version
should I use? Keep in mind the /parent/module layout in the filesystem
(with relativePath) is not an absolute requirement ie parent poms
could/should be checked into a Maven repo and resolved from there. The
fact that ../pom.xml usually works to find the parent is just an
enhancement to the functionality.
So assuming I have 3 parent pom versions in my Maven repo, how does
Maven know which one is right without being told?
It could be told by setting -Dmy_version=version and using
${my_version} in the parent reference. But not even that works.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: generating site from parent
Wayne Fay wrote: This is discussed a couple times every week. Please search this list for parent site or just check out this recent thread: from Morgovsky, Alexander (US - Glen Mills) to users@maven.apache.org date Nov 9, 2006 4:03 PM subject Aggregate site generation I did that, and it doesn't work. I get a menu with the sub project names, but no links. The project summary seems to give me links, but they link back to the top. It is really weird. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Trouble with aggregate javadoc
running the javadoc plugin with aggregate set to true fails with unresolved dependency errors. I note that the unresolved dependencies stem from a portion of the source tree to be compiled and run with the 1.4 JRE. Could that affect javadoc and how can I fix it? Here are the types of messages I see: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation. Embedded error: Exit code: 1 - /local/home/cg/a/main/src/java/common/src/main/java/com/sensage/util/EmailUtil.java:4: package javax.mail.internet does not exist import javax.mail.internet.InternetAddress; The project builds, of course, and the dependency is declared... -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
Eric Redmond wrote:
I see what you are trying to do... but why? If you do not define a child
project's version, it automatically inherits from its parent. Just take
version${main.version}/version out.
The trouble is that you need a -reference- to the parent's version in
the children, and that reference does not seem to resolve any ${...}
substitutions, so it needs to be hard coded. In other words, you get to
query/replace all of your project's pom.xml files whenever you bump the
version number.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
generating site from parent
How come generating the site from the parent project does not result in a collection of all the sites of all the sub-projects? Is there no aggregate site, or what is the magic XML for that? TIA -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I resolve ${...} in assembly descriptors?
Jochen Wiedmann wrote:
On 11/17/06, Christian Goetze [EMAIL PROTECTED] wrote:
I'd like to pass in something either via the environment or via -D on
the mvn command line, and have that be visible within the assembly
description. How do I do that?
Use a filtered resource to create the actual assembly descriptor. In
other words,
if your assembly descriptor with ${DO} is src/main/assembly/bin.xml,
then specify src/main/assembly as a filtered resource. That will
give you a file target/classes/bin.xml, which you'll give as a
descriptor to the assembly plugin.
Neat! Vielen Dank!
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Embedded Error while rendering javadocs
I added the javadocs plugin to generate an aggregate report, and I see this: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - /local/home/cg/a/main/src/java/common/src/main/java/com/sensage/util/EmailUtil.java:4: package javax.mail.internet does not exist import javax.mail.internet.InternetAddress; ^ /local/home/cg/a/main/src/java/common/src/main/java/com/sensage/sls/client/Request.java:8: package org.apache.xerces.jaxp does not exist import org.apache.xerces.jaxp.DocumentBuilderFactoryImpl; ^ (with a lot more) It seems that somehow, it needs to know the dependencies of my project, so why doesn't use the dependencies as declared? what is really going on? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I resolve ${...} in assembly descriptors?
I'd like to pass in something either via the environment or via -D on
the mvn command line, and have that be visible within the assembly
description. How do I do that?
For example, I'd like to say:
fileSet
directorysrc/main/bat/${DO}/bat/directory
outputDirectorybin/outputDirectory
includes
include*.bat/include
/includes
/fileSet
(For those asking why: ${DO} maps to my external build system's
equivalent of the target directory in maven, and it's the one which
generates the files to be included - and please don't tell me I need to
give that up - thanks)
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Version management question
I recently asked the question below, but no answer.
I was wondering whether I really need to edit all pom.xml files in all
my project whenever I bump version numbers.
I'm still new at this, so if this is a trivial question, please bear
with me...
--
cg
Christian Goetze wrote:
Why can't I do this:
project
modelVersion4.0.0/modelVersion
!-- This project belongs to ... --
parent
groupIdcom.sensage/groupId
artifactIdsensage/artifactId
version${sensage-version}/version
/parent
I do run mvn -Dsensage-version=3.6...
It works fine when I run from the top of the project down.
--
cg
-
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: Version management question
Lee Meador wrote: This does not work. If you think about it you can see why. You would define 'sensage-version' in the parent pom and use it in all the children. The problem is that as it is parsing the child pom, maven has to find the parent. To do that, it looks in the parent section and has to use the value of sensage-version'. Not really, since I pass in the value of sensage-version via a -D flag. Maven just refuses to resolve it within a parent.../parent section. Its a classic catch-22 situation. You can't find the parent without the value of 'sensage-version' and you you can't find the value of 'sensage-versin' without the parent. Yeah, I guess so... I'm wondering, though, why maven can't just go look in the parent directory for a pom.xml file and not require me to specify where the parent is - after all, maven has no qualms about imposing all sorts of directory structure conventions, so why not just go that extra step, or at least have a tag use whatever is in the parent directory Meanwhile, I guess I just need to live with having to manage all versions in all the pom.xml files by hand - sigh -. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why does ${...} replacement not work within parent.../parent?
Why can't I do this:
project
modelVersion4.0.0/modelVersion
!-- This project belongs to ... --
parent
groupIdcom.sensage/groupId
artifactIdsensage/artifactId
version${sensage-version}/version
/parent
I do run mvn -Dsensage-version=3.6...
It works fine when I run from the top of the project down.
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How do I avoid install error when using dir assembly?
I'd like to avoid getting the following error, but still have an - bin.dir file available: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact: /local/home/cg/a/fremont/src/java/cli/DO/i386-RedHat-linux26/debug/target/cli-3.6-bin.dir (Is a directory) Is there a magic exclude I can insert someplace? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I set project.version externally?
So I have a project with modules, and every module has its pom.xml file
with a reference to the parent, which must include the parent version.
All of these version numbers should be the same. I tried writing:
parent
groupIdcom.sensage/groupId
artifactIdsensage/artifactId
version${project.version}/version
/parent
but this fails.
Is there no way to do this centrally, do I really need to go and edit
all the pom.xml files every time the version changes?
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Looking for a simple maven assembly example
I've read the better builds with maven book, I've looked at http://maven.apache.org/plugins/maven-assembly-plugin, but I'm still not sure I understand how this is supposed to work. I just want end up with a zip file containing all of the jars needed to run the particular project I'm building. Alternatively, I'd already be happy with a way to just get the transitive runtime dependency list out of the build. Any help would be appreciated, thanks in advance. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How do people include version info into the build?
With this, I mean how do people ensure that the version number used in the build is available at runtime? Do people generate a property file with the version number and include it in the jar? Anyone have a nice little example for this? Thanks in advance... -- cg - an obvious maven2 newbie... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Looking for a simple maven assembly example
Dirk Starke wrote: Hello Christian, I am just starting to use Maven 2, also had some problems to figure this out, and perhaps I can help you. In my little project I created two files in the src/main/assembly directory of my project. Thanks, but it only ends up with the one jar in the project. How do I get it to include all jars needed to run, as expressed in the dependencies? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re Looking for a simple maven assembly example
Thanks, but it only ends up with the one jar in the project. How do I get it to include all jars needed to run, as expressed in the dependencies? -- cg Oops, sorry, the other nice person who answered has the clue... Thanks again! -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Packing applications and jar signing
What do people do to assemble all the jars required to run a specific application (i.e. a specific jar), pack them and get them signed? I currently use rpm for packing, and my idea was to explicitly list the jars and sign them from the spec file, but perhaps there is a better way? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do some jars in ibiblio do not have .pom files?
Dan Tran wrote: axis group has been moved to org/apache/axis, that could be the reason why nobody bothers to fix the missing pom. - In ibiblio, I see org.apache.axis, and underneath I only see jars, not poms. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do some jars in ibiblio do not have .pom files?
Dan Tran wrote: are you sure? http://repo1.maven.org/maven2/org/apache/axis/axis/1.4/ OK, that's not the same as http://www.ibiblio.org/maven/. I'll add this one to my proxy -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do some jars in ibiblio do not have .pom files?
Dan Tran wrote: are you sure? http://repo1.maven.org/maven2/org/apache/axis/axis/1.4/ Oh, I see it now - the groupid changed too that's going to be so much fun down the road when repositories will have a gazillion things in it and somebody decides to clean up -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why do some jars in ibiblio do not have .pom files?
Just wondering - examples include: axis/axis-saaj/1.4/axis-saaj-1.4.pom axis/axis-jaxrpc/1.4/axis-jaxrpc-1.4.pom Of course I can create my own in my own proxy, but would like to know whether there is a deeper reason. -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Has anyone made a jwsdp-1.6 repository?
Before I start on ther path of rolling my own, I was wondering if anyone already did this -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How do people search for jars and poms?
If this is a stupid question, I apologise in advance... Given a dependency to a specific set of classes, how do people locate the jar that provides it, together with the artifact and group ids? I haven't yet found a better way than to search through ibiblio, hoping to find something there - but to locate things like javax.xml.rpc.*, it's not easy. As you can tell, I'm in the process of converting an ant based system with lots of checked in .jar files to a maven system. The trouble with the checked in .jar files is that they are completely void of any version info, and I need to reconstruct the dependency tree by hand. How do the pros do it? -- cg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there a guide to all the ${...} macros?
As the subject says...
I'm wondering if everything I pass in via a -D flag is available as a
${...} macro in the pom.xml file. Also, are environment variables
available? Is it possible to define or compute values within the pom.xml
file?
One of several reasons I'm asking is because I need to integrate maven
into a large scale (including non-java code) build system which is the
authoritative source for information like version numbers, repository
locations etc. I can, of course, have it generate pom.xml files from
templates, but would rather not do that...
--
cg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
