snapshot built locally
I understand that a SNAPSHOT dependency will be pulled from my local repository, and once a day maven will make a check for a newer version in remote repositories known to the build. Is this behavior the same if the SNAPSHOT dependency in local was built and installed from a local build?
RE: How does Maven download the latest snapshot from Nexus?
> The magic is inside maven-metadata.xml that will be generated while uploading. And who is responsible for generating the meta-data . . . the repository? Or Maven itself? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency plugin loses file permissions
After handcrafting an assembly to set my permissions just write, I then pull that assembly artifact, a zip file, down into another build. This build uses the dependency plugin to unpack the zip. But when it does so, it loses my permissions . . . is this supposed to be happening? What can I do?
RE: clean execution with absolute path
Nevermind. I'm not sure what was going on here. It works as advertised. > -Original Message- > From: chad.da...@emc.com [mailto:chad.da...@emc.com] > Sent: Thursday, July 05, 2012 2:07 PM > To: users@maven.apache.org > Subject: clean execution with absolute path > > I can't seem to figure out how to configure the clean plugin to delete a > fileset > in a directory defined with an absolute path. I have to have the path > relative > to the build, it seems. Is there a way to configure the clean plugin to > delete > stuff at arbitrary location that isn't relative to the build? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
clean execution with absolute path
I can't seem to figure out how to configure the clean plugin to delete a fileset in a directory defined with an absolute path. I have to have the path relative to the build, it seems. Is there a way to configure the clean plugin to delete stuff at arbitrary location that isn't relative to the build?
structuring builds
I'm beginning to sense that the structure of your build, e.g. the choices you make in grouping certain builds into multi-module builds and how you structure your directories in source control, have huge impacts on the ease of doing software lifecycle things like branches and future releases. Does anyone know of any discussion of this topic? Blog entry? Book? Etc.
purpose of pom.xml in the META-INF
What are the general reasons for having the pom deployed into the META-INF? What kind of use cases leverage this info?
RE: war overlays file merging
> > Is it possible to have a merge of files that exist in both wars? > > I'm not quite sure how that would work. You'd have to write pretty > smart code to handle the various types of files and merges which are > possible. > How do people manage source files that are additive between overlay wars then? For instance, I'm doing an overlay of a struts application. They both have a struts.properties file. It seems that if I change something in the base war's properties file, I'll have to remember to move it up to the second one too . . . It seems that it would be nice for these to be additive . . . but maybe I'm not thinking of this correctly. Maybe there's no good solution here, or maybe I'm misusing overlays.
war overlays file merging
Is it possible to have a merge of files that exist in both wars?
RE: compile plugin
>
> Run "whereis java" ("where java" in Windows) to find out how many java
> executable you might have in PATH and which one is listed first. That's where
> I'd start.
I'm beyond that phase already, but thanks. I'm on linux, and the mvn start up
script checks
JAVA_HOME to see which version of java to use. This works, but it doesn't seem
to propogate down to the javac invocation by the compile plugin.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: compile plugin
Hi Martin. I saw that actually. It seems kind of hacky to me . . . like, a workaround for my local java installations, and I don't want to modify the build for my own dev situation. It seems like if I set the JAVA_HOME for mvn, it should use the java I'm telling it to . . . do you have any thoughts on why that doesn't work? Thanks, Chad > -Original Message- > From: martin.eisengardt [mailto:martin.eisenga...@googlemail.com] > Sent: Monday, June 25, 2012 10:51 AM > To: Maven Users List > Subject: Re: compile plugin > > Hi. > > See the example at > http://maven.apache.org/plugins/maven-compiler- > plugin/examples/compile-using-different-jdk.html > > Greetings > Martin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
compile plugin
I've got multiple jdk's installed. I'm trying to force maven to use my java 7. I invoke mvn with a JAVA_HOME value that points to my desired jdk, but then the compile plugin complains about 1.7 not being a valid source setting . . . seems like the JAVA_HOME doesn't control the execution of the compile plugin . . . Ideas?
RE: Central repository not being hit
> I'm a relative newbie to Maven. When you say "effective pom" are you > referring to the project's pom or a global pom for Maven? If global, where > would it be located? > The "effective pom" is your pom plus all the stuff it inherits from parent poms it declares, and from the Maven "super pom". The super pom is the built in pom that defines all of the default values, such as maven central as a remote repository. The maven help plugin has a goal you can execute to get the effective pom for a given pom. http://maven.apache.org/plugins/maven-help-plugin/ Go to the directory where your pom is, and execute: mvn help:effective-pom All IDE maven plugins will show you this as well. BTW, if you are a maven newbie, here's some advice on how not to get in trouble. http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but-maven-docs-do.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Central repository not being hit
You should check the effective pom. I think that's a part of the maven help plugin. > -Original Message- > From: Hartzman, Les X. -ND [mailto:les.x.hartzman@disney.com] > Sent: Friday, June 01, 2012 10:35 AM > To: users@maven.apache.org > Subject: Central repository not being hit > > Hi, > > We have a build machine with 2.2.1 on it and it is not querying > repo1.maven.org when it can't find a dependency in a local repository. > > There are no mirrors defined to override this. Not until the repo was added > to the settings.xml did the dependency get downloaded. > > Is this a configuration issue? I thought that the central repository was hit > by > default. > > Thanks. > > Les - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: timestamped and non-timestamped snapshots in repo together
> > I think it's more of a Nexus question as it depends on what's in the maven- > metadata.xml file. Maven never scraps the folders but uses the metadata. > > What error do you get? Why not just remove the non-timestamped > Snapshots? Or, just wipe all the Snapshots and issue new build of them giving > you nice, timestamped, unique Snpashots. > The error said the it couldn't find the artifact in any repositories, and ends with recommending that you download the artifacts from the website and install it in your local repo. However, the URL in the output line about trying to download it would actually be valid, and even work if you copied it into a browser for instance. Anyhow, I think I have it fixed now. I believe the issue was a "corrupt" index. Or perhaps out of date. I re-indexed and everything works. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
timestamped and non-timestamped snapshots in repo together
We're having problems with a build not being able to download snapshots from nexus. We use timestamped snapshots, but I noticed that there are also non-timestamped, i.e. they just say myArtifact-1.0.0-SNAPSHOT.jar, in there. I belive these came from someone doing a "redploy artifacts" from an older version of nexus. Would this be expected to cause problems?
RE: unpacked dependency in assembly question
> So your problem is with the unzip stage where it is creating a top level > directory and putting the files in it instead of exporting just the files > into the > output directory? > Perhaps you want to share your current method of doing that? Hey Ron. It's not that it's creating a top level directory, the zip contains a top level directory. My method is nothing more than this: false org.apache.tomcat:apache-tomcat true catalina_base/myApp So, what happens here is that the tomcat distribution is a zip, and it's root folder is "apache-tomcat-5.5.35". I'd like the contents of that folder dumped into my target output directory, but it, of course, just unzips the archive into that folder, leaving me with an extra folder I want to eliminate. FYI: I'm trying to create an assembly that prepares a zip of my tomcat app deployment following best practice separation of CATALINA_HOME from CATALINA_BASE. This requires me create a pure version of the dist, under CATALINA_HOME, and a modified version of the dist, under CATALINE_BASE. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: unpacked dependency in assembly question
My question wasn't all that clear. My problem is this. I have a zip dependency that I'm unpacking into my assembly. I'd like to trim out the root folder of that zip's contents, so I can just dump the contents of that root folder into my output directory. I'm having trouble figuring anyway to do this. Ideas? > -Original Message- > From: chad.da...@emc.com [mailto:chad.da...@emc.com] > Sent: Friday, May 25, 2012 9:12 AM > To: users@maven.apache.org > Subject: unpacked dependency in assembly question > > Is it possible to change the name of the folder into which the dependency is > unpacked? Seems like there is no equivalent to the non-unpacked > outputFileNameMapping? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
unpacked dependency in assembly question
Is it possible to change the name of the folder into which the dependency is unpacked? Seems like there is no equivalent to the non-unpacked outputFileNameMapping?
RE: The Maven Way
> Good read. > Thanks. > I think it says something that it has not been done yet. While everyone says > it would be great to have, clearly no one has felt strongly enough about it > (yet) to make it happen. It is more of a very nice to have than a hard and > fast > requirement. I'm tackling the topic on my blog in upcoming weeks. The first thing I'm going to talk about is how Maven expects all dependencies to be handled via repositories, and how to make non-standard artifact types work like this, such as custom assemblies, etc. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The Maven Way
> Especially since the most valuable single > > bit of advice one can give a new Maven user is: "if you don't do > > things Maven's way, Maven will fight you and Maven will win." > > > > I disagree that it is the "most valuable single bit of advice." It is > repeated far > too frequently, often in cases where there *is* a reasonable technical > answer to the question being asked. > > Maven is much more flexible than many give it credit for. You can write your > own plugins to do nearly anything, or invoke Ant with AntRun if you have > existing Ant-based builds I would have to disagree here. For instance, writing your own plugins is a horrible idea unless you are very, very, very wise maven user. The problem is that the docs talk a lot about how it's a plugin architecture and how you can write your own mojo's. I've just dealt with a project where they wrote their own mojo's for a bunch of stuff that was already provided by other existing plugins. The documentation should emphasize the existing body of plugins and provide a guide to the most useful of those and BURY the concept of writing your own. I think the whole notion of configuring or customizing maven in any way is a very tricky issue. It's front page on the docs, but it's the kind of thing that would best be put in Chapter 19 of a long book that covered all of the standard stuff before even broaching the topic. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: The Maven Way
> You are not alone in that. Especially since the most valuable single bit of > advice one can give a new Maven user is: "if you don't do things Maven's > way, Maven will fight you and Maven will win." > > People extol the virtues of "convention over configuration", but where is the > compact definitive specification of The Conventions? > Interestingly, I just wrote a detailed blog entry about the irony of a CoC tool with a body of documentation that documents the configuration rather than the conventions. It's kind of darkly humorous if you think about it. The configuration is the way to get in trouble with maven, but it's the only thing documented. In case you're interested: http://zeroinsertionforce.blogspot.com/2012/04/maven-does-not-suck-but-maven-docs-do.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: JRE as mavne artifact
> > Our build has a dependency on the JRE. In order to build our final > > distribution artifact, we need a JRE. To me, this means that the JRE > > should be managed as a maven artifact in nexus. Otherwise, > > I don't understand the use case. Please describe it in more detail. > My installer is more for our people to build "appliance" boxes that contain our technological solution. So, we are actually trying to install the whole thing. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
JRE as mavne artifact
Our build has a dependency on the JRE. In order to build our final distribution artifact, we need a JRE. To me, this means that the JRE should be managed as a maven artifact in nexus. Otherwise, I can't use the assembly plugin to build my distribution. I can't really find much on this on the internet, though I do see a couple of people suggesting that it's a whacky idea. Why is it whacky? The JRE is a raw material upon which our build is dependent, so how else should that be obtained? Other ways of making it available to the build don't seem better . . . How do other people solve this problem?
timestamps on files in assembly
I'm wondering if I can preserve a timestamp on an artifact in my assembly so that it stays equal to when it was originally built, i.e. the build time, or at least the deploy to nexus time - very similar timestamps obviously. My scenario and observations. I'm using an assembly to prepare a distribution archive. That archive contains several other artifacts that we build. In my deployed distribution I've noticed that the component artifacts have per file timestamps roughly equal to the Jenkins build time of the distribution build. After some investigation, I've determined that those timestamps are equal to when the artifact is pulled down from nexus into the local repository; I've observed this in an non Jenkins environment, i.e. my local dev env, where the timestamp is actually equal to the time the artifact was downloaded into my local repository. So, is it possible to make the artifact retain its "original" timestamp across all of the building processes?
RE: How to include librabries when compile with Maven?
> You might also want to switch from Eclipse to Eclipse STS from the Spring > guys. > This gives you Eclipse and Maven in the IDE all from a single download. > We have used it for a few years now and it is much better than Eclipse on its > own. Is that packaged with m2e as the maven plugin, or does spring provide its own maven plugin? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
build-helper:attach-artifact
I'm using the attach-artifact to attach a binary installer that I build. Everything works great, but I don't quite understand the sequencing requirements. For instance, it appears to work okay if I run the attach-artifact prior to the exec:exec mojo that actually creates the installer. Is this expected? Is it just a metadata action?
RE: Attach a random file to the deploy process
> Well, kinda - that only allows you to adjust extension and classifier. > > I _know_, we're swimming up stream here a bit. > > I'm pulling down the code for the buildhelper - I'd like to be able to control > final name or artifactId at least :-/ I would suggest that controlling the name of the artifact is flagrant violation of the maven way. I just did a bunch of this work and I used the classifier to clearly identify the purpose of the attached artifact. Assuming your .doc file was something like "release notes", you could use a classifier of "releaseNotes". I assume your desire to use a different name comes from other elements of your ecosystem wanting/ needing a different name . . . ? I suggest changing those things if possible. If they really have to be named something else, perhaps they should be attached to another project with that name. Or even deployed ad hoc via the deploy:deploy-file mojo? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: useing profiles to control properties to drive version numbers in poms
> > Not good. > Dependency versions should be deterministic. For the same reason avoid > version ranges. > > That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: repository id question
So, the id is only used to match the credential declarations ? > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Monday, February 27, 2012 9:44 AM > To: Maven Users List > Subject: Re: repository id question > > if they all use the same credentials, I would say no issues > > On 27 February 2012 16:08, wrote: > > Are there issues with the re-use of the same repository id across the > various repository declarations? As "identifiers", it seems like they should > each be unique. Is there anything wrong with the following . . . > > > > > > > > myRepo > > Internal Repo > > > > http://myRepo/nexus/content/groups/public< > /url> > > > > > > > > > > myRepo > > Internal Repo > > http://myRepo > /nexus/content/groups/public > > > > > > > > > > > > myRepo > > Internal Releases > > http://myRepo > /nexus/content/repositories/releases > > > > > > myRepo > > Snapshots > > http://myRepo > /nexus/content/repositories/snapshots > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
repository id question
Are there issues with the re-use of the same repository id across the various repository declarations? As "identifiers", it seems like they should each be unique. Is there anything wrong with the following . . . myRepo Internal Repo http://myRepo/nexus/content/groups/public myRepo Internal Repo http://myRepo /nexus/content/groups/public myRepo Internal Releases http://myRepo /nexus/content/repositories/releases myRepo Snapshots http://myRepo /nexus/content/repositories/snapshots
RE: Lookup from WAR to external JAR
> Hi, > I'm trying to set up a WAR project which uses NetBeans Lookup to find > services in external JAR files. Right now, I define an interface in the WAR > and > the implementations in a couple of JAR projects. I tried adding a dependency > on the WAR to the JAR poms, but mvn clean package doesn't seem to like > that. > > 0. Is this the right design, or should I be doing something different? > 1. What am I missing that I need to make this work? > What do you mean by "doesn't like"? It sounds like you probably have a circular dependency: your jars must depend upon the interfaces in the war, but doesn't your war depend upon the jars since they'll probably be built into the web app? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: customizing the snapshot version build number
> P.S. I think screwing around with the Maven snapshot naming scheme is > asking for trouble. Putting it in the manifest seems safer to me. > Unfortunately, you didn't elaborate on *why* you want to do this, so we > can't really comment on any alternative solutions. > Oh, I can elaborate ;) This is currently how my team traces its way back from an binary artifact in the field to source control checkins. I assume there are much better ways to do this, but, my approach, is an incremental re-work of our nonstandard build with an eye towards the lowest hanging fruit, iteratively. Know what I mean? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: One question about Multi Project Structure in MAVEN
> So basically i have to use deploy plugin to deploy the stuffs at repository > and > over there i can define what components i want to publish or deployed. Sometimes the definitions are kind of vague in the maven literature. A "repository" is simply the thing that holds your maven artifacts. There's your "local" one, .m2, and zero to many "remote" ones. "Deploy" means put the artifact in a remote repository. "Install" means put it in your local one. The remote ones can be public, or private. You most assuredly want a private one. At some point, you might also deploy a publicly distributable artifact to a public repository, like maven central, so the public can get to it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
customizing the snapshot version build number
I'm trying to figure out a way to get my Hudson build number onto my snapshot artifact names. I noticed that the timestamp in the snapshot unique version number is followed by a build number. Is there way to inject my own value here, the Hudson build number for instance.
classifiers and packaging types
I'd like to have a better understanding of classifiers and package types. The packaging type is supposed to indicate the package type of the artifact. Simple enough. But does this carry through to any extra artifacts that I might attach to the pom? Or is this purely for the "primary" artifact. And, then, when attaching other artifacts to the pom, is packaging even useful? Or should I use classifier for this task?
dependency plugin usage
I'm wondering what the difference would be between the following two ways of handling copying of a certain type of maven dependency. The dependency I'm talking about is something like, for instance, a self-extracting installer that I want to bundle with my custom assembly. I've deployed this installer as a maven artifact. Initially, I didn't think of it as a normal maven dependency, since it's not a compile dependency, so I set the build up to use the maven-dependency-plugin:copy mojo. This works great. However, I then started wondering whether I should just declare the dependency in my dependencies and then use the maven-dependency-plugin:copy-dependencies mojo. Can anyone provide some insight as to whether either way is better or worse?
RE: how to hanlde .run binary as a maven artifact
> Chad, instead of > > run > > I think you use - > > run > Hey, Wes! How are things? Thanks for the info. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: how to hanlde .run binary as a maven artifact
> 2) How do I go about getting my .run binary installed into nexus by maven, > i.e. by the deploy phase? Note, I've already figured out how to get my build > to put the .run file into the target directory, so I really just need to > figure out > how to get maven to deploy it, right? Thanks! > > Use the build helper plugin with the attach-artifact goal and bind it to the > appropriate life cycle phase after it is generated .. then mvn deploy will > push > it to your repo. So, my packaging would remain "pom", and I would be attaching it a .run file as an additional artifact . . . that make's sense. How then would my dependency look in the poms that depend upon the .run artifact? Like the following? com.mygroup myproj run - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
how to hanlde .run binary as a maven artifact
I'm trying to figure out how to best handle a .run binary as a maven artifact. My build produces a single binary executable, a ".run" file. Currently this is done with a maven exec plugin firing off an script, all tied to the install phase. The package type of the pom is "pom". So, this, to my mind, isn't really doing it the maven way. Moreover, I'd like to make that .run binary a maven artifact in my nexus repository so it can be accessed by other projects which need it in their builds. 1) Is it wrong to handle a binary such as this via maven/nexus? 2) How do I go about getting my .run binary installed into nexus by maven, i.e. by the deploy phase? Note, I've already figured out how to get my build to put the .run file into the target directory, so I really just need to figure out how to get maven to deploy it, right? Thanks!
timestamped snapshots in local repo
Are there supposed to be timestamp uniquely named snapshot artifacts in my local repo? I'm investigating the uniqueVersion = false setting to solve a disks space problem, but I read some threads here and there that expressed disagreement on whether there should actually be an accumulation of the these uniquely named artifacts in a local repo under normal operating conditions. I assume they show up there whenever a build has a snapshot dependency. I know that "installing" a snapshot doesn't create a uniquely named one, in contrast.
Difference between compile and provided scope for jar artifacts
When I build a jar file, the compile dependencies are not packaged into the jar. So, this means that they are expected to be provided somewhere else in the run time environment, doesn't it? Which means that it doesn't seem like there's a difference between compile and provided . . . am I missing something?
deploying custom build artifact
I'm using the maven-exec-plugin to run a process that produces a binary executable, let's call it "myBin.run" I would like to treat this as my maven artifact, i.e. have it deployed to my nexus repository during the deploy phase. What's the best way to do this? The deploy:deploy mojo seems like it might work, but it doesn't appear to have the configuration that would allow me to tell it about my custom artifact file. The deploy:deploy-file mojo has those configurations, but the docs make it sound as if it's to be used outside the scope of an actual maven build. Advice? Other options?
