Re: Maven Enforcer Plugin, requirePluginVersions, and Maven 3.0
On Sep 8, 2010, at 11:14 AM, Brian Fox wrote: > The workaround is to not use > this rule in M3 anymore since the core will throw warnings at you > anyway. For the requireMavenVersion and requireJavaVersion rules, should I continue using Enforcer, or is there a Maven 3 analog for them as well? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Enforcer Plugin, requirePluginVersions, and Maven 3.0
Hi, I'm trying out Maven 3.0-beta-3, and one of the first things I noticed is a new warning message: [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (enforce-rules) @ MyApp --- [WARNING] This rule is not compatible with the current version of Maven. The rule is not able to perform any checks. The warning is caused by the presence of the following Maven Enforcer rule: I seem to remember reading somewhere that Maven 3.0 already has the functionality of requirePluginVersions. In any case, what's the proper way to resolve this warning? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven failing due to javac path issue -- Windows
On Sep 7, 2010, at 9:34 AM, Enrique Gaona wrote: > Can't say if it works with Oracle's JDK, since I've not tried it before. > Trying with Oracle's would help determine where the problem lies. > One workaround would be specify the maven-compiler-plugin in the parent > pom.xml, but I really don't want to do that. > Can't you just point JAVA_HOME and your PATH to the Oracle JDK? Trevor
Re: Maven failing due to javac path issue -- Windows
On Sep 7, 2010, at 9:25 AM, Enrique Gaona wrote: > Output from the variables: > C:\RTC-data\workspace>echo %JAVA_HOME% > C:\IBM\ibm-java-sdk-60-win-i386\sdk Does it work on Oracle's JDK instead of IBM's? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 4:35 AM, Stephen Connolly wrote: > not without wagon, just not with the webdav wagon Sorry, I'm still confused. The Wagon docs [1] list the following providers: * File * HTTP * HTTP lightweight * FTP * SSH/SCP * WebDAV * SCM (in progress) Of the three that are accessible over HTTP (HTTP, HTTP lightweight, and WebDAV), only WebDAV allows deployment, according to the docs. If WebDAV is not used, how are artifacts uploaded to the server? Trevor [1] http://maven.apache.org/wagon/index.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 6:48 AM, Ron Wheeler wrote: > Get Nexus up and running and start to enjoy using Maven. I'm sensing a theme here. Anybody reminded of that old joke? "Doctor, it hurts when I move my arm like this." Doctor: "Then don't move your arm like that." > It is free. It is easy to install and configure. ... > We are a small team of 3 but it was well worth the time to get it up and > running. That you are a small team of 3 is very likely the reason why you found it easy to install and configure. I'm assuming one of you 3 set up the server yourself, correct? And had root access to it? You probably didn't have to expose Nexus outside the firewall, either. These are all advantages I'm lacking. I'm working remotely as an external contractor and have no control over the company's servers. And it doesn't help that I'm the only person using Maven in an all-Microsoft shop. They'd have to integrate the Nexus server's user account management with Microsoft Active Directory. (Is that even possible?) And they'd also have to configure their firewall just for me so that I may access Nexus from the outside. This is a company with thousands of employees and a full-time IT security engineer; punching holes in their walls is not something they take lightly. In short, installing Nexus is by no means easy. But the company already happens to have a web server with SFTP access outside the firewall. They've given me an account on it. I'm simply trying to piggyback on this as a repository and use SFTP for deployment, since SFTP is a "supported" deployment method. Please correct me if I'm wrong about that. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 7:22 AM, Justin Edelson wrote: > Can you use SCP instead of SFTP? I tried that, but it fails with "Remote connection terminated unexpectedly". I suspect this is because shell access to the server is disabled. (Trying to ssh to it gives "PTY allocation request failed on channel 0 \ shell request failed on channel 0".) Or is shell access not required for SCP? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 4:01 AM, Stephen Connolly wrote: > Actually no, AFAIK use http direct, so it's not the WebDAV client at all. Hmm... so how are artifacts deployed without Wagon? The Wagon docs say that deployment over HTTP is not supported. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 4:01 AM, Stephen Connolly wrote: > Your client would be better served using a Maven Repository Manager than a > website backed by an SFTP share. Drink the Kool-aid No small feat. I am the lone Java developer in an enterprise that is 100% C#. They already drank the Kool-Aid, and it tastes like Seattle. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 3:17 AM, Stephen Connolly wrote: > Because they all deploy via http/https So in other words, use WebDAV and then I will not be worrying about SFTP at all. Well, yes, naturally. But at the moment my client only has an SFTP server, and as far as I know, the SFTP transport in Maven Wagon isn't deprecated. I don't think I'm doing anything unusual by deploying with SFTP. In fact, my understanding is that it's pretty common. Therefore I'm hoping to enlist help in tackling this bug instead of just working around it. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
On Sep 6, 2010, at 1:49 AM, Stephen Connolly wrote: > Use A Maven repository manager and then you will not be worrying about sftp > at all. How does a repository manager eliminate the need for SFTP? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Deploy with SFTP tries to cd to parent too many times
Hi, I'm running into a build failure when doing "mvn deploy" via SFTP. This appears to be a bug that affects any repository whose SFTP host disallows access to the root directory. Here's what I know so far: By instrumenting JSch (which does the actual SFTP commands), I can see that the problem occurs when JSch issues a "cd .." too many times. In fact, it does "cd .." all the way back to the root and just keeps on going, doing a "cd .." several more times. Ordinarily this wouldn't be a problem, but when the permissions of the SFTP user don't allow cd'ing into the root directory (for increased security), there will be a permission denied error, which in turn causes the build to fail. Assuming that the security policy of the server cannot be altered, I'm trying to figure out if there's a way to resolve this on the client side. However, I have no idea why Deploy is trying to "cd .." so many times. For example, if I configure the snapshots repository as something like: sftp://example.com/home/myuser/myrepository/snapshots Then there's no need to cd anywhere above the "snapshots" directory. But Deploy does exactly that, for some reason. From studying the logs I put into JSch, Deploy appears to be trying to check the repo for previous artifact metadata, and to do so it issues a "cd" into a directory deep in the hierarchy. But because this artifact doesn't happen to be in the repo, the directory does not exist, yet the code continues on as if it does. It then issues a series of "cd .." commands, which, if the directory existed, would probably bring it back to some appropriate spot in the hierarchy, but because the first "cd" failed, it starts from a much higher level and ends up ascending well past the root. Any thoughts? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Overriding a dependency in Maven's uberjar
Hi, I was getting an exception when deploying, so I needed to figure out exactly what SFTP commands were being issued. The stack trace indicated that JSch was issuing the commands, but it didn't seem to have any kind of debug switch, at least not one that I could enable from Maven. I decided to build JSch from source with my own logging statements inserted. This would require overriding the JSch dependency with my own version, as described here: http://www.sonatype.com/people/2008/04/how-to-override-a-plugins-dependency-in-maven/ But this didn't work at all. No matter what I tried, Maven refused to load my version of JSch. Fast forward through 90 minutes of hair pulling, and I finally figured out that Maven was ignoring my local repository and instead loading a copy of JSch that happened to be in its uberjar. So my question is... Is there some way I should have known this? What knowledge could I have had that would have told me that any attempt at loading a dependency from my local repo would fail because the dependency is in the uberjar? I'm asking not only to improve my understanding of Maven but also to question if there's some way to change Maven, or simply add to its documentation, so that this problem doesn't bite other users. Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching platform-specific executables as secondary artifacts
On Aug 16, 2010, at 5:19 PM, Trevor Harmon wrote: > On Aug 16, 2010, at 5:04 PM, Justin Edelson wrote: > >> http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html > > Thanks, that looks like just what I need. I experimented some more with this issue, and it turns out I don't need build-helper at all. If I bind the osxappbundle and launch4j plugins to the package phase, they're automatically deployed to my repository when doing "mvn deploy" (or "mvn release:perform"). Strangely, this doesn't happen if I bind them to the deploy phase instead. I'm not sure what's going on behind the scenes. I assume there's some code inside the two plugins that knows what to do for the deploy phase. Is this common behavior for these types of plugins? Anyway, I've decided to keep the plugins attached to my package phase, despite the increase in build time. Things are simpler that way, and the delta is a lot less than the last time I tested these plugins -- no more than 10 seconds or so. (This new SSD drive I got is da bomb...) Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven properties not accessible in xhtml
On Aug 16, 2010, at 9:05 AM, wrote:
> The site came up as expected but the html did not interpret the
> ${project.name} and it was printed as it is. In comparison when I used apt,
> then the html does show the name which maven reads from the POM.xml
When I use APT, built-in properties such as ${project.name} are not evaluated
and instead show up as-is. I have to add a ".vm" extension to the APT file and
also define the properties I want to use in my POM, taking care not to use
periods. For example:
${project.version}
I can then use ${projectVersion} in my APT file and it is evaluated correctly.
This is as directed by the Site plugin docs. See the section on Filtering:
http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html#filtering
I'm not sure how you were able to get it to work without doing this. But
perhaps the tactic will solve your XHTML problem.
Trevor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching platform-specific executables as secondary artifacts
On Aug 16, 2010, at 5:24 PM, Justin Edelson wrote: >> Can you think of any potential >> problems in binding build-helper to the deploy phase instead? Thanks, > Well, that would mean the artifacts never end up in your local > repository, which seems weird. Good point, but in this case the artifacts will never have anything depending on them, so I don't see a need to have them in the local repository. And if I do need to generate the executables without deploying them (e.g. for testing), both plugins have goals that can be run on an as-needed basis. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attaching platform-specific executables as secondary artifacts
On Aug 16, 2010, at 5:04 PM, Justin Edelson wrote: http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html Thanks, that looks like just what I need. The only problem is that it binds by default to the package phase, which would require binding the launch4j and osxappbundle goals to the package phase as well. This would greatly increase build times -- the executables take awhile to generate -- even when I'm in normal development mode, not yet deploying. Can you think of any potential problems in binding build-helper to the deploy phase instead? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Attaching platform-specific executables as secondary artifacts
Hi, My project is a Java GUI app, and when I deploy it, its JAR artifact is uploaded to the repository. I also use a couple of plugins to generate platform-specific executables for the app: launch4j [1] and osxappbundle [2]. I'd like to deploy these executables to the repository too, so that there's a fixed URL from which they can be downloaded. (In fact, I can't think of a reason to deploy the JAR artifact at all; only the executables need to be published.) My understanding is that this can be accomplished by attaching the executables to my project as "secondary artifacts". But how is that done? The plugins themselves don't appear to have any specific support for this. They simply dump the executable into my project's target directory. Would I use the Assembly plugin? Or something else? I just can't seem to find any documentation or discussion of this issue. Thanks, Trevor [1] http://alakai.org/reference/plugins/launch4j-plugin-usage.html [2] http://mojo.codehaus.org/osxappbundle-maven-plugin/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: External repository always requires a repository manager?
On Aug 16, 2010, at 12:29 PM, Justin Edelson wrote: Okay, let me make sure I understand this. Say I've got a main artifact and a customized plugin that it depends on. I can configure the plugin to deploy to my own remote repository by adding the repository info to the plugin POM's . I would use altDeploymentRepository instead of modifying the POM. http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository ... * run mvn -DaltDeploymentRepository=foo::default::scp://myrepo/foo deploy I don't see the advantage of altDeploymentRepository. What's wrong with modifying the POM? I'd prefer not to have to remember a command line parameter and just do a simple "mvn deploy". Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: External repository always requires a repository manager?
On Aug 16, 2010, at 10:18 AM, Justin Edelson wrote: One "in and out" to learn is that your distinction of "internal" and "external" repositories isn't found in Maven. I found it here: http://docs.codehaus.org/display/MAVENUSER/Maven+Concepts+Repositories Is the term "external repository" not valid? Also, I just wanted to be a good Maven citizen and take a load off Central, if that wasn't too hard to do. Again, as a single developer, it isn't possible to take load off Central (or mirrors) because you always need to download artifacts at least once. And unless you do the things I said above, you never need to download artifacts *more than once*. I guess I was thinking of SNAPSHOT dependencies, in which case Central would be queried on every build, right? But then, I never depend on SNAPSHOT versions of external artifacts, so yeah, it wouldn't make much difference. But perhaps the most important reason is that I need to deploy customized versions of some Maven plugins. There are a couple I'm using on Central that are buggy, and might not be updated for awhile, so I need to deploy and use versions that have the bugs fixed. It's not clear to me if I need a repository manager for that, or if I can get away with the non-managed repository I have now for deploying project artifacts (and the site). You don't need a repository manager for this. You can deploy these artifacts to your own remote repository. Okay, let me make sure I understand this. Say I've got a main artifact and a customized plugin that it depends on. I can configure the plugin to deploy to my own remote repository by adding the repository info to the plugin POM's . So now the plugin is available in my repository. But here's where I get a little confused... How does the main artifact know how to retrieve the deployed plugin from my remote repository? Do I simply add the remote repository URL to the main POM's ? (This seems to be discouraged: "I have yet to hear a convincing argument for doing so" [1]) Or should I add it to ? Or somewhere else? Thanks, Trevor [1] http://maven.apache.org/pom.html#Plugin_Repositories - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: External repository always requires a repository manager?
On Aug 16, 2010, at 7:20 AM, Justin Edelson wrote: > But if you are a single developer, I'm not sure what value you are > looking to get out of this. Your local Maven repository acts as a local > cache, so unless you need to blow this away with some regularity, what's > the point? Well, I'm a single developer now, but before long the project will grow, and maybe spawn new projects. I'd prefer to learn the ins and outs of repositories when the project is small and manageable. I was also intrigued by the promise to "shave minutes off a build" [1] and was wondering if this does in fact require a repository manager or could be accomplished more simply. Also, I just wanted to be a good Maven citizen and take a load off Central, if that wasn't too hard to do. But perhaps the most important reason is that I need to deploy customized versions of some Maven plugins. There are a couple I'm using on Central that are buggy, and might not be updated for awhile, so I need to deploy and use versions that have the bugs fixed. It's not clear to me if I need a repository manager for that, or if I can get away with the non-managed repository I have now for deploying project artifacts (and the site). Trevor [1] http://maven.apache.org/repository-management.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: External repository always requires a repository manager?
On Aug 16, 2010, at 4:48 AM, Ron Wheeler wrote: > Find a provider that lets you run your own application. > Put it on a cloud service. Yes, those are ways around the shared hosting problem, but as soon as I have to purchase and manage separate server space just to run a repository manager, it is no longer trivial. (At least, not as trivial as it is to set up site and artifact deployment, which only require an HTTP server and some way to upload the files.) > Read the Nexus docs on how to set up a deployment. Is there a specific section I should be looking at? I can't seem to find anything about deployment without a repository manager. Everything I've read in the Nexus docs is in the context of a repository manager. Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: External repository always requires a repository manager?
On Aug 16, 2010, at 1:20 AM, Stephen Connolly wrote: > Your life would be much easier using a repository manager for your > "internal" repository. Nexus is almost trivial to set up, for example. It is trivial to set up *if* you have the necessary permissions to set up the service. In my case, I'm an independent contractor, and the only server I personally have access to is from one of those shared hosting providers, and it's simply not possible to run Jetty or Tanuki in that kind of environment. My client does have their own servers, but I'd have to make a special request to get one of their IT guys to set it up for me. So unless you've got root access to your own server... not trivial. > As for internal vs external, there is no difference, you don't need a > repository manager... Okay, but I'm just not understanding how to configure Maven for that. Sure, I could set up a element like this: central http://repo.myserver.com/repository/ And that tells Maven to check the above URL for artifacts before going out to repo1.maven.org. But it only knows how to download, not upload. How can Maven put the newly downloaded artifacts into this repository? (I thought that's what a repository manager is for...) Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
External repository always requires a repository manager?
Hi, I've set up an "internal" repository for deploying project artifacts. It was remarkably easy to do. All I needed was some web space with SCP access. After that it was only a matter of configuring my POM's to point to the URL. No repository manager needed. Now I'd like to set up an "external" repository. (Not sure if that's the right term.) The only purpose would be to cache artifacts so that Maven can download them from my repository instead of making a trip out to Central. However, it appears that this type of repository is not so easy to set up. My understanding is that it would require the use of a repository manager. I'm hoping to avoid that, since repository managers have to run as a background service (e.g., in a Java EE container). This would really complicate things, mainly because I don't have root access to the server and would have to get special permission to set up the service. Am I correct in thinking that an external repository necessarily requires setting up a repository manager? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Velocity bug fixed in 2007 still affects JXR users
On Aug 15, 2010, at 11:10 AM, Dennis Lundberg wrote: > Can you please open an issue in JIRA for this at: > http://jira.codehaus.org/browse/JXR http://jira.codehaus.org/browse/JXR-84 Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Velocity bug fixed in 2007 still affects JXR users
Hi, There was a bug in Velocity that was causing a spurious error message to be printed: [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any resource loader. [INFO] Velocimacro : error using VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'VM_global_library.vm' This affects many Maven users who include JXR reports with their site generation. That is because JXR uses Velocity, and thus the innocuous error would be displayed on every "mvn site". With the release of Velocity 1.5 in 2007, the bug was fixed: https://issues.apache.org/jira/browse/VELOCITY-86 But even when using the latest versions of JXR (2.2) and the Site plugin (2.1.1), the error message still appears. This is because somewhere in the dependency tree, the old Velocity 1.4 release is being pulled in, as this snippet of "mvn -X site" reveals: [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus:pom:1.0.11 for project: null:plexus-utils:jar:1.5.1 from the repository. [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1:runtime (selected for runtime) [DEBUG] velocity:velocity:jar:1.4:runtime (selected for runtime) [DEBUG] velocity:velocity-dep:jar:1.4:runtime (selected for runtime) The proper fix is to locate the component that is using Velocity and update it to use Velocity 1.5, but I'm not sure which component that is. I checked JXR and plexus-utils, but neither has a direct dependency on Velocity. I do see that the latest release of plexus-velocity, 1.1.8, was changed to use Velocity 1.5 instead of 1.4, but when I override the JXR plugin to depend on it (instead of the older 1.1.2), the build fails: Embedded error: Error rendering Maven report: Error while generating the HTML source code of the projet. The specified class for ResourceManager (org.apache.velocity.runtime.resource.ResourceManagerImpl) does not implement org.apache.velocity.runtime.resource.ResourceManager; Velocity is not initialized correctly. At this point I'm stumped. Any suggestions? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: PMD plugin: source xref not generated unless JXR runs first
On Aug 13, 2010, at 11:48 PM, Lukas Theussl wrote: > if you want it to work with 'mvn site' you have to configure the jxr plugin > as a report, see http://maven.apache.org/plugins/maven-jxr-plugin/usage.html Worked great; thanks! How can I help add this to the documentation? It was not at all clear to me... Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is release:perform optional?
On Jun 7, 2010, at 3:52 PM, Mark Derricutt wrote: Add the osxappbundle:bundle and launch4j:launch4j goals to the element. You mean the element, like this? org.apache.maven.plugins maven-release-plugin 2.0 clean verify osxappbundle:bundle launch4j:launch4j Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is release:perform optional?
On Jun 7, 2010, at 3:22 PM, Justin Edelson wrote: If you don't do release:perform, how does the release artifact get created? The release artifacts for my project (a stand-alone Java desktop app) are created using the osxappbundle and launch4j plugins. So my release process is: 1. Tag the current trunk 2. Check out and build the tagged release 3. Run "mvn osxappbundle:bundle" to create the Mac release artifact 4. Run "mvn launch4j:launch4j" to create the Windows release artifact 5. Grab the resulting .dmg and .exe files from /target and email them to the client There's no formal deploy process because I'm just one guy working on a little desktop app. Setting up a repository would seem like overkill. Does it make sense to skip release:perform in this context? Perhaps another option (instead of simply skipping release:perform) is to configure the deploy:deploy goal with skip=true. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding extra jar dependencies to maven build
On Jun 7, 2010, at 2:36 PM, scabbage wrote: I have a project which contains some internal jar files I got from someone. These jar files are not in any repository, so I cannot add them as . You could add them as a with a scope of "system". http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Is release:perform optional?
Hi, I need a quick-and-easy way of tagging the current snapshot and bumping up the version number of my POM. The Release plugin can do this in one step with its release:prepare goal. However, the plugin then expects me to run release:perform, which as far as I can tell simply invokes the deploy and site-deploy phases. But I'm not doing any deployment, and I have no repository. Can I simply skip release:perform? My intent is to run release:prepare followed by release:clean, thereby getting the benefit of release:prepare without having to do an actual deploy. Or would there be some problem with that? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Best practices for developing Java applets with Maven
Hi, I'm developing a plain old run-of-the-mill Java applet. Yes, just a simple stand-alone applet, not bundled with a WAR file or anything like that. I use Maven to build the class files and JAR, but what then? Is there a "standard" Maven way of loading the applet in a browser (locally) to view it and test it? Currently I've just got an index.html file in an "html" subdirectory of the project root. The HTML loads the applet by pointing its applet tag to "../target/MyApplet-0.1-SNAPSHOT.jar". This hard-coded path bothers me, but I'm not sure how to do anything better in the "Maven way". There don't seem to be any plugins or other Maven mechanisms designed for applet development. Are there any tips or tricks I should know about? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with buggy plugins
On Dec 26, 2009, at 4:04 AM, Dan Tran wrote: > Another option is the fork the plugin into your SCM, that is even worse You mean the binaries or the source? I agree that managing JARs in an SCM is not a good idea, but I don't see anything wrong with putting a patched branch of the plugin into my SCM. I'm not sure how the patches would be managed otherwise. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with buggy plugins
On Dec 26, 2009, at 5:41 AM, Anders Hammar wrote: > Well, I'd say it's better to install the MRM (Nexus or Artifactory) on a > server in your development network. All your developers will be dependent on > this to get the patched plugins (or any other internal artifacts). A couple of issues with that: First, there are no other developers, just me. (It's a one-man hobby project that happens to use Maven for builds.) Second, I don't really have a server that could host an MRM. I do have an account with a shared web host, but I don't think it's possible to install, say, Nexus in that kind of environment. I've got my personal workstation, and that's pretty much it. So, should I just run the MRM locally? Or do I even need to bother with an MRM? I don't really see any advantages to an MRM given my circumstances. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with buggy plugins
On Dec 26, 2009, at 3:15 AM, Dan Tran wrote: > you must have your own repo and cut your own > internal release of the plugin with your fixes. Why exactly is a repo necessary? Setting one up just to host a couple of patched plugins for my personal use seems like overkill. If it is required, what exactly is involved in having my own repo? Could that be as simple as installing Nexus locally on my development machine? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dealing with buggy plugins
One of my projects depends on a couple of third-party plugins available on Central. These plugins provide key functionality for the build, but they also contain some serious bugs. Let's say I fix these bugs myself and submit patches to the maintainers. It could be months before the patches are reviewed, committed, and eventually show up as a new plugin release on Central. I certainly can't wait around for my patches to be applied, so what are my options in the meantime? Should I simply install the patched plugin locally? Or would it be better (for any definition of that word) to set up my own repository manager and deploy them there? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there a way to specify a particular SNAPSHOT version?
On Jun 10, 2009, at 4:03 AM, U Gopalakrishnan wrote: pick up a new snapshot version only once in every 2 weeks or so. You might be able to do this by setting the snapshots updatePolicy of your settings.xml to "interval:XXX" (XXX in minutes). Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Direclty commit in svn without a workingdirectory
On Jun 10, 2009, at 3:28 AM, Nafter wrote: Is it possible with maven and ANT to directly commit and overwrite a file in subversion without a workingdirectory on the disc? I don't think this is possible in Subversion, so it wouldn't be possible in Maven or Ant, either. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: $JAVA_HOME ignored?
On Jun 9, 2009, at 5:49 PM, Elliot Huntington wrote: Why is it then that in order to have maven compile my project for 1.5 I need to use the following? Maven's compiler plugin always defaults to a Java 1.3 target, regardless of the host VM version. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: wagon:upload fails only with release:perform
On Jun 9, 2009, at 10:21 AM, Dan Tran wrote: Release plugin does not know about command line goals, but only a phase goal. I'm not sure what a command line goal is. I think you mean it only works with phases, not goals. But that's contrary to both the documentation and my experience using the plugin. The docs say that the element in the configuration takes a list of goals, and indeed, this works just as expected. For instance, I've added a couple of goals to the element, osxappbundle:bundle and launch4j:launch4j, and they work perfectly fine. It's only the wagon:upload goal that has problems. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: wagon:upload fails only with release:perform
On Jun 9, 2009, at 3:56 AM, Reinhard Nägele wrote: I guess it should work, yes. At least I would not know why it doesn't. I filed a bug on it: http://jira.codehaus.org/browse/MRELEASE-453 Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: wagon:upload fails only with release:perform
On Jun 9, 2009, at 3:26 AM, Reinhard Nägele wrote: Have you tried to create an execution for the wagon plugin that is bound to the install phase instead of adding the wagon:upload to the release plugin goals? No, because the wagon:upload goal is uploading files produced by the release plugin, and if I'm only doing an install, the release files might not be there (e.g., because of a clean). Also, even if the files were there, I don't want to upload a bunch of files to a remote server every time I do an install. That would really slow down my development cycle. Shouldn't it work the way I'm doing it now? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
wagon:upload fails only with release:perform
Hi,
I'm using release:perform, and it works perfectly in the standard
configuration. But now I'm trying to modify it so that an additional
goal is invoked as part of the release:perform process. The additional
goal is wagon:upload, which I've configured to upload some files to a
server via SCP.
I tested the wagon goal by running "mvn wagon:upload", and it worked
fine. So, I simply added "wagon:upload" to the list of goals in the
release:perform plugin. As expected, running "mvn release:perform -
DconnectionUrl=..." starts the usual release:perform process, but now
it fails at the end with an error:
[INFO] [INFO] One or more required plugin parameters are invalid/
missing for 'wagon:upload'
[INFO]
[INFO] [0] Inside the definition for plugin 'wagon-maven-plugin'
specify the following:
[INFO]
[INFO]
[INFO] ...
[INFO] VALUE
[INFO]
[INFO]
[INFO] -OR-
[INFO]
[INFO] on the command line, specify: '-Dwagon.url=VALUE'
This is baffling because there are no errors when running wagon:upload
directly. And I've checked and re-checked the plugin configuration.
The element is there, and it all looks good.
I've attached the POM I'm using, with all of the extraneous stuff
removed. I've also anonymized the SCM configuration, so it's not a
repeatable test case, but otherwise it shows the exact configuration
that triggers the error.
Am I doing something wrong, or should I file a bug report on this?
Thanks,
Trevor
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.test
Test
jar
1.0-SNAPSHOT
scm:svn:http://test.com/test/trunk
scm:svn:http://test.com/test/trunk
org.codehaus.mojo
wagon-maven-plugin
1.0-beta-1
${project.build.directory}/checkout/target
${project.build.finalName}.jar
scp://test.com
/home/user/test
org.apache.maven.plugins
maven-release-plugin
2.0-beta-9
install wagon:upload
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 26, 2009, at 12:52 PM, Todd Thiessen wrote: I don't think so. When Bob merges the trunk to branch he will have both Alice's changes and his. When he does an install, the 2.2-SNAPSHOT version will contain both his and Alices changes for all modules. Yes, but AppB will still reference Foo 2.1-SNAPSHOT. Therein lies the problem. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 5:07 PM, Sean Hennessy wrote: Evidence to the contrary that Bob and Alice are working independently is they share development on single artifact Foo. They're working independently on AppA and AppB, but they're sharing the work of developing Foo. Ensure Alice and Bob communicate daily on the development plan, schedule and status. Yes, that is true. Alice should have told Bob that she released Foo 2.1, and that development on the trunk is now at version 2.2-SNAPSHOT, and that Bob should update his AppB to depend on this new version. That would have definitely solved Bob's problem. But the side-effect is that whenever there's a new release of a dependency, emails must be sent and POM files must be updated. For Alice's and Bob's simple scenario, that's not a big deal. But consider a real-world scenario with many developers and perhaps dozens of interwoven dependencies. The stream of new releases causes a flurry of communication and lots of POM editing, especially if the development teams are following a "release early, release often" kind of strategy. The overhead is not scalable, especially in the face of human error. (An email could be forgotten, or a POM file could be updated with the wrong version number.) In fact, all this overhead encourages developers to *avoid* releasing new versions of dependencies. They want to work with X-SNAPSHOT for as long as possible simply to avoid the extra work of putting out a new version, even if it's just an internal release. (This is precisely the problem we're facing in my team and is what prompted the original post.) Of course, staying with a SNAPSHOT release for extended periods complicates regression testing and other quality assurance tasks. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 5:28 PM, Brian E. Fox wrote: Do we assume that bob is unable to see that the version he currently works on and compiles, tests, installs and maybe deploys has 2.2-snapshot written all over it? Yes. Maven generates a lot of output to the console, and it's easy to ignore all the text that scrolls by. Even if the output were minimal, Bob is updating and rebuilding his working copy of Foo several times a day. He's not in the habit of examining the build output closely, at least not when the build succeeds, as in this scenario. Sure, he might notice the version change eventually, but perhaps not before he wastes a couple of hours debugging the problem. Also, consider that Foo may not be the only shared library that Bob's AppB depends on. There could be Bar, Bat, Baz, Xyzzy, and Thud as well. These libraries might be under active development too, and their versions may change periodically. With all these version numbers floating around, even if Bob notices that Foo is 2.2-SNAPSHOT today, he might have simply forgotten that it was 2.1-SNAPSHOT yesterday. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 3:29 PM, Todd Thiessen wrote: Bob should work on a branch. IMHO if any work is taking a long time and you can't commit it to trunk in a timely manner, then do that work on a branch so you can commit often and still take specific control over when Alice's changes get merged to Bob's branch so he can test the merge thoroughly before putting his changes in trunk. This does not solve Bob's problem. Let's say he's committing to his branch, and then at some point he merges Alice's changes to the trunk into his branch. He then performs thorough testing of this new code and encounters no problems. But of course he won't have any problems testing the new Foo 2.2-SNAPSHOT because AppB is still still using the old code from Foo 2.1-SNAPSHOT. Until he realizes that Foo's version has changed, and he updates AppB accordingly, branching, merging, and testing won't help him. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 3:26 PM, Martin Gainty wrote: someone is assigned mainline of code and someone-else assigned a branch (this happens when core is heavily customised for a customer's needs where the user-specific mods will be integrated by merge-branch later on) This does not solve Bob's problem. Assume that Bob is working on a branch of Foo. At some point he will A) merge the trunk's changes into his branch, or B) merge the branch into the trunk and then switch to the trunk. If this happens after Alice increments Foo's trunk to 2.2- SNAPSHOT, the problem will occur. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Mar 25, 2009, at 10:26 PM, Martin Gainty wrote: The only way to accomplish this is called version control I thought it was clear in the first paragraph that version control is involved: "They have both checked out Foo's trunk and are regularly committing changes to it." There are several other indications as well, such as the description of Alice tagging the code base and Bob updating his working copy. To be absolutely clear, Alice and Bob are both using version control. All code, including AppA, AppB, and Foo are managed in a source code repository. But I don't think this improves the situation in any way. As Ben noted, the scenario shows version control working as designed. but since you do not want to use version control .. Why do you think this? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: archetype:generate gives "Desired archetype does not exist"
On Mar 25, 2009, at 1:34 PM, Trevor Harmon wrote: Using Maven 2.0.10, if I do: mvn -e archetype:generate then press Enter when it prompts me for a number, I get errors: Found the problem. I'm using a local installation of Nexus as a mirror of central, but the local installation was down. After removing the entry in my settings.xml, the error went away. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Possible problem when multiple developers depend on SNAPSHOT versions
Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
archetype:generate gives "Desired archetype does not exist"
Using Maven 2.0.10, if I do: mvn -e archetype:generate then press Enter when it prompts me for a number, I get errors: [WARNING] repository metadata for: 'artifact org.apache.maven.archetypes:maven-archetype-quickstart' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted . . . org.apache.maven.BuildFailureException: The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype-quickstart:RELEASE) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 580) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:228) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java: 430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype- quickstart:RELEASE) at org .apache .maven .archetype .mojos .CreateProjectFromArchetypeMojo .execute(CreateProjectFromArchetypeMojo.java:201) at org .apache .maven .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 559) ... 16 more Any suggestions? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Does a plugin with no executions need to be marked inherited?
Hi, I have a parent POM that configures the Compiler plugin for Java 1.4. It modifies the plugin's configuration and does not define any goals or executions. In such a situation, does setting the plugin's element to true have any effect? For example: org.apache.maven.plugins maven-compiler-plugin 1.4 1.4 true My tests (using help:effective-pom) indicate that has no effect on whether this configuration get passed on to children, but does anyone know for sure? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Extracting classpath for an application from maven
On Mar 7, 2009, at 3:11 AM, Roman Kournjaev wrote: I have a maven based application, well now i want to run it in cmd mode, it means just executing the compiled class. I use exec:java for this. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: slightly [ot] Help setting up a MAC for Maven
On Feb 12, 2009, at 5:31 PM, Mick Knutson wrote: I am used to configuring Windows and Linux as a developer machine. But want to setup a mac now. And I am finding it tough to add maven 2.0.9 along with MAVEN_HOME, as well as a newer JDK 6 and JAVA_HOME so I can run command line builds on a Mac. Can anyone point me to a tutorial or something? I prefer using a package manager such as Fink or MacPorts to install Maven. They can download, install, and set up environment variables in one step, and they make removing or upgrading packages just as easy. http://www.finkproject.org/ http://www.macports.org/ Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: slightly [ot] Help setting up a MAC for Maven
On Feb 12, 2009, at 5:50 PM, David C. Hicks wrote: As far as I know, there is no Java6 for Mac, yet. There is, but the Apple-provided one is only for 64-bit Intel machines running Leopard. An alternative is SoyLatte: http://landonf.bikemonkey.org/static/soylatte/ Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: executing maven-exec-plugin twice doesn't seem to work
On Feb 12, 2009, at 3:42 PM, klimane wrote: I am trying to get a maven-exec-plugin to run two different main programs in a particular order within the same build. Have you looked at this? http://article.gmane.org/gmane.comp.java.maven-plugins.mojo.user/1307 Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Character encoding for APT files
On Jan 22, 2009, at 4:50 PM, Hervé BOUTEMY wrote: Sorry, I was working on other things and missed this discussion. I just commented (and closed as "Not A Bug" :) ) the issue. I agree that autodetecting is not a bullet-proof feature, but an absolute guarantee is not required in this case. I share Jason van Zyl's view: "If it's right most of the time, and it saves the user from having to know or worry about it then yes I would use it." [1] Another issue is that without autodetection, supporting more than one type of character encoding for the APT files in a Maven project is impossible. That said, if autodetection is simply out of the question, let me suggest a different tack. Doxia appears to require ISO-8859-1 for APT files by default. This is a Western-centric encoding that lacks support for Asian languages. It is also deprecated. According to Wikipedia: "The ISO/IEC working group responsible for maintaining eight-bit coded character sets disbanded and ceased all maintenance of ISO 8859, including ISO 8859-1, in order to concentrate on the Universal Character Set and Unicode." [2] I would also say that with the increasing popularity of UTF-8, the number of encoding problems encountered by users due to Doxia favoring ISO-8859-1 is already larger than any problems that might occur due to bad autodetection. In other words, autodetection might be wrong some of the time, but for many users, ISO-8859-1 is wrong all of the time. In light of this, I suggest changing Doxia's APT handling so that it defaults to UTF-8 rather than ISO-8859-1. Not only will this help UTF-8 users (who may be a majority), it will also help increase Maven's acceptance in the Asian world, a trend that is already happening [3]. I can work on a patch for this, if there's a chance it will be accepted. Trevor [1] http://www.nabble.com/Re%3A--VOTE--POM-Element-for-Source-File-Encoding-p16566779.html [2] http://en.wikipedia.org/wiki/ISO_8859-1 [3] http://blogs.sonatype.com/people/2008/07/apache-maven-the-definitive-chinese-guide/
Hierarchical multi-module projects in a source code repository
Hi, I have a multi-module project that is stored in a flat directory structure in our source code repository (Subversion). For example: repo parent trunk tags branches child1 trunk tags branches child2 trunk tags branches Note that parent, child1, and child2 are all on the same level. I would like to change this organization so that child1 and child2 are children of the parent. This is the usual way of organizing multi- module projects, since it makes their relationship clear. But what about the problem of repository branches? For example, if I make child1 and child2 children of the parent, it will look like this: repo parent trunk child1 trunk tags branches child2 trunk tags branches tags branches This is clearly an invalid directory structure (from a repository perspective) because the parent's trunk includes the children's branches. So, will I simply have to give up child branches if I want to use this kind of hierarchy? I am loathe to do this, since it would force the children to have the same version as the parent. Perhaps my current organization -- that is, flattening the module directories so that they're all siblings -- is the only way to do it... Any thoughts? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Use of profiles
On Jan 16, 2009, at 1:55 PM, Eric Rotick wrote: My requirement was simply to allow for common sections to be collected together to enhance the maintainability of the pom. Currently the verbose nature of the pom makes it far too easy to have subtle differences that ruin the test. We're having a similar problem with our install4j code, which is basically 30 lines of Ant that gets copied and pasted to each new project that needs to build an installer. Of course, this can introduce bugs, especially when one of the 30 lines needs to change, and that change has to propagate to all the projects. To solve this problem, I'm writing a plugin that factors out the common code into a single place. The projects can then reference the plugin and specify just enough information that's unique to their setup. Perhaps a similar solution would work in your case. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Use of profiles
On Jan 15, 2009, at 7:09 AM, Eric Rotick wrote: So, the first question is, is this use of profiles correct? I can see that primary purpose of profiles is to set up, well profiles, of different scenarios for the build. In this respect the use of profiles for specific tests falls loosely into this category. However, the use of profiles to perform a kind of macro or script does not seem correct. This sounds like the same question I had in this thread: http://mail-archives.apache.org/mod_mbox/maven-users/200812.mbox/%3c9bbf0d0d-1db8-4e6d-8bb0-fb8d0939c...@vocaro.com%3e The ideal solution is to write your own custom test plugin, "mytest" or whatever. You can then invoke it directly, like this: mvn mytest:test1 mvn mytest:test2 ... Or you can bind it to a phase and have it run automatically. Of course, writing your own plugin involves extra work and maintenance, so as an alternative you can simply put your test invocation code into a profile and simply enable that profile as needed. This is not kosher, as you point out, but it's an acceptable workaround for test scenarios. At least, this is my conclusion based on the responses in the thread. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Executing a plugin from another plugin
Hi, I have a custom plugin that I've written, and I need it to call out to some other plugin. For example, I've got the following code in a POM: maven-assembly-plugin installer package directory-single src/assembly/production-assembly.xml I want to take all that code out of the POM and have it execute inside my plugin instead. I assume this would require invoking the Mojo API. Any tips on how to do this? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
APT into HTML without sidebar/header/footer
Hi, I have some documents authored in APT that get bundled with the project web site when doing "mvn site". This transforms the APTs into separate HTML files, but each one has a copy of the site's sidebar, header, and footer. This is fine when viewing the document as part of the site, but if I want to, say, email one of the documents to an outside party, it will include this extraneous information that they don't want to see. So, I need to generate a version of the HTML without all the site-specific stuff. What's the best way to do this? Will I have to write a script to invoke doxia-converter or aptconvert explicitly? If so, how would I integrate that script into the Maven project? Thanks, Trevor
Implicitly defined anchors
The APT reference in the Doxia documentation says:
"Section titles are implicitly defined anchors."
I assume this means I can create an anchor link to a section without
having to explicitly define an anchor for that section.
I've tried to use this feature by putting the name of a top-level
section between double curly braces (e.g., {{Installation}}), and it
does create an anchor link in the HTML (e.g., href="#Installation">), but it doesn't go anywhere. There's no
corresponding anchor in the HTML (e.g., ).
It all works as expected if I explicitly make an anchor out of the
section title.
Is this a bug, or have I misunderstood the documentation? Thanks,
Trevor
Project documentation (with Doxia)
I'm getting started with Doxia but have run into some issues. 1) "mvn site" converts my APT files to HTML, but I want them converted to PDF as well. I know PDF generation is possible with the "aptconvert" utility, but how can I do it with Maven, preferably as part of the site phase? 2) Many of the figures referenced by my APT file are authored in some proprietary format (e.g. UML illustrations), then they're converted into PNG and placed into src/site/resources/images so that they can be accessed by the generated HTML. But where do I store the original files? Should I just place them alongside the PNG files in the images directory, even though that will copy them into the site's target directory for no reason? 3) What if I have documentation that doesn't really belong in the project web site? For instance, we've got an Adobe Illustrator document for printing a high-quality PDF user guide. Is there a Maven convention on where it belongs? (Maven's standard directory layout only addresses developer-facing files and doesn't mention anything about end-user documentation.) Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Block level elements do not appear in output
On Jan 12, 2009, at 8:14 AM, Lukas Theussl wrote: You use 'mvn site' to generate apt files from apt source files? I guess you mean html? In this case the title and author end up in the html , so you don't see them when you view the file with a browser. Yes, sorry, I meant that I'm generating from APT, not to APT. It's odd that the generator puts the title and author into the HTML but makes them invisible. And it ignores the date completely. Doesn't that defeat the purpose of adding this information? Trevor
Book descriptor seems too complicated
Hi, My goal is to generate a PDF of an APT file alongside the HTML that gets generated by default when running "mvn site". It appears that writing a book descriptor is the only way to do this. However, the book descriptor mechanism seems way too complicated. It requires me to list explicitly all of the sections in my APT file. But then, if I ever change the APT file sections, I have to change the book descriptor too. Mistakes can easily happen that way. Why can't Doxia simply derive the sections from the ones that are declared in the APT file itself? Also, it appears that each section has to be split up into its own file. Again, this seems unnecessary. My APT file is small, and the sections are clearly defined within it. Splitting it up into multiple files would only make it more difficult to edit. Is there a way around these problems? Thanks, Trevor
Re: Launching a stand-alone test program
On Jan 7, 2009, at 5:01 PM, Kalle Korhonen wrote: If it's a manually run test application I'd create a separate module for it. You can set the main application as a dependency of this module, then spit out the required classpath with dependency:build-classpath and put the run parameters in your pom file, then write them out to a filtered shell or batch script. Is there some advantage to building the classpath and script manually? I'd have thought using the Exec plugin would be a lot simpler. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Launching a stand-alone test program
On Jan 7, 2009, at 12:56 PM, Wendy Smoak wrote: FWIW, I rely on my IDE to do this kind of thing. There's usually a "Run" configuration you can set up, and it figures out the classpath for you, lets you set parameters, etc. Setting up a Run configuration in an IDE is fine for a single user. But what about: 1) All members of your team need to set up the same configuration (lots of redundant manual effort) 2) The run parameters may change (each member has to perform the redundant manual effort again) Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Launching a stand-alone test program
On Jan 7, 2009, at 12:20 PM, John Stoneham wrote: If you're just running a standalone program that doesn't really need to interact with anything that's in the POM or be tied to the Maven lifecycle or dependencies, no sense trying to couple it into Maven. I should have clarified what I meant by "stand-alone". It is stand- alone in the sense that it's not built on JUnit or a similar automated testing framework. But since it's testing the application, it does need to know the classpath (i.e. dependencies) that Maven sets up for the primary app. That's why the launching needs to be integrated with Maven. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Launching a stand-alone test program
Hi, In addition to the usual automated unit tests that run in Maven's test phase, I now need to add a special kind of test program. It's stand- alone, requires user interaction, and should be run only occasionally, not during every test phase. As for location, I assume I should just put it somewhere in src/test/ java, but what about invoking it? How would I configure the POM file so that users can launch this test program only when needed, on demand, rather than on every "mvn test"? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Deploying a customized plugin
There's a plugin I'd like to use, but it has some bugs that prevent me from doing so. Fortunately, it's an open-source plugin, so I was able to fix the bugs, but I'm not sure how to make the fixes available to others on my team. Although I've submitted bug reports, there's no telling when (or if) the bugs will be fixed upstream. I assume the best option is to change the version of my bug-fixed plugin, deploy it to the team's repository, and have the other developers reference this custom version number rather than the one on Central. Then, if the same bugs are ever fixed upstream, the developers can simply reference that version instead, and the one on the team repository will no longer be used. Is that the right course of action? If so, is there a convention on how to choose a version number for this customized plugin? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 22, 2008, at 12:38 PM, Todd Thiessen wrote: I think the reason why you are having so much trouble with Maven is that you want to "configure" it to do what you want by giving it a specific command. But actually, I can give Maven a specific command to do what I want ... as long as a plugin exists for it. Take for example DocBook. There's a plugin for that, so I can invoke one of its goals explicitly, or at the same time I can have it run automatically by binding it to a phase. That's exactly the kind of flexibility I need. For install4j, however, there's no plugin, so I have to emulate one with AntRun. That's when my problems start, since there's no way to target a particular AntRun configuration without using profiles. So I think the lesson here is that I should try to avoid AntRun and Exec, and use a specific plugin for the task, even if that means writing my own. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 19, 2008, at 4:24 PM, Baptiste MATHUS wrote: And I'm also really wondering why you try to use maven in what seems to me an ant-ish way. I made a mistake in even mentioning Ant. It seems to give a sense that I'm closed-minded and unable to think in the "Maven way". I should have simply asked, "How do I do such-and-such in Maven?" and left it at that. If you need more specific and totally unrelated tasks, and you don't want a predefined packaging lifecycle I don't know how I've given the impression that I'm trying to avoid the Maven lifecycle, or that I somehow want to twist Maven into an Ant clone. I'm simply giving examples of use cases that are common in my development cycle and wanting to know how to implement them with Maven. like maven provides you with, why don't you simply use ant alone? We used to use Ant, but the management decided to switch to Maven. I guess the idea was to take advantage of the broader Maven features such as dependency resolution, convention-over-configuration, and so on. However, I'm now facing difficulty trying to do things in Maven that we used to do with Ant -- building an installer, launching desktop apps in two different ways, etc. It seems that Maven makes some tasks very simple, but at the same time it makes others very complex. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 17, 2008, at 12:18 PM, Martin Höller wrote: Ok. My approach would then be to create one profile which is only executed before releasing or when running in the contiuous-integration server. This profile would configure the antrun plugin to execute install4j, run integration tests, and do some other time-consuming work. Yes, that's what I've been doing, but you said I was doing it wrong. I just wanted to make sure that profiles were the only way to do it in Maven, or if there was some other technique I didn't know about. You say it: it runs all of the _configurations_, but it's still only _one_ goal that runs. In this case the 'run' goal of the antrun plugin. The antrun plugin is kind of special as it runs ant task within maven, which doesn't have the concept of tasks. The exec plugin is like that too, and I find both to be very integral to the development process. Perhaps these plugins need a new feature that allows the user to specify which configuration is used. Something like: mvn exec:java:config1 mvn exec:java:config2 mvn antrun:run:config1 mvn antrun:run:config2 Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 17, 2008, at 11:45 AM, Geoffrey Wiseman wrote: All I'm really trying to say (and I suspect what others are trying to say) is that the answer to your original question, "Are profiles intended to play the same role as Ant targets?" is "No. They aren't." Yes, I was trying to simplify things with that subject line but I guess I just made them more confusing. Perhaps a better question would be, "Are Maven profiles the only way to accomplish what I was able to accomplish with Ant targets?" I hadn't thought about using modules for this; I will look into it. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 17, 2008, at 3:54 AM, Martin Höller wrote: And BTW: Maven's primary goal is to help building and packaging software, not starting the developed piece of software, so IMHO the exec- plugin is not a good example here. Well I have to disagree with you there. Testing is also not about building and packaging software, yet Maven provides lots of support for testing because it's such an integral part of the development process. Launching a desktop application that's being developed is part of testing too. Also, I don't want to maintain separate scripts in a separate language just to launch an application. How would I make sure that the source code has been compiled? How would I locate all the dependent JARs? These problems are handled by the exec plugin, so I see no reason not to use it just because profiles are "bad". I simply want to keep everything contained within Maven, like I was able to do with Ant. For example, in Ant I was able to define targets like "run-test1" and "run-test2" that had dependencies on "compile" and "jar". That way, whenever I ran either test, Ant would make sure that the JAR was up to date with the latest code. I don't know of any way to duplicate this functionality without using profiles. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 17, 2008, at 3:33 AM, Martin Höller wrote: mvn -Pinstall4j package Why would you have to use a profile for this? Because it takes five minutes to run. I don't want to wait five minutes every time I package, install, or deploy my code. The install4j stuff only needs to happen when we're ready to ship the final installer to the customer. Without profiles, I don't know how to exercise control over when this time-consuming process kicks off. If you really want maven to do only _one_ specific thing (which is most of the time not the common way) you can execute a single plugin goal by specifying just this goal, e.g. "mvn deploy:deploy-file" or "mvn antrun:run". No, specifying a single goal does not run a single goal, it runs ALL of the configurations for that goal. I've attached a sample POM to demonstrate. Try this: mvn antrun:run package You will see both of the antrun:run configurations run. In that same POM, I've also shown how to run just one of the configurations using profiles. For example: mvn -Phello package mvn -Pgoodbye package Is there a way to achieve that without profiles? Trevor http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.vocaro antrun 1.0 pom maven-antrun-plugin say-hello package hello run maven-antrun-plugin say-goodbye package goodbye run hello maven-antrun-plugin say-hello package hello (profile) run goodbye maven-antrun-plugin say-goodbye package goodbye (profile) run - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 17, 2008, at 9:14 AM, Todd Thiessen wrote: This prints hello and goodbye as part of the clean phase. ... Doesn't this fit your needs? No, it doesn't fit my needs because it always prints both "hello" and "goodbye". I want to print either "hello" or "goodbye". For example, in the scenario I mentioned earlier, I want to launch a desktop application with one particular command-line configuration. With your solution, I'd be launching the app multiple times. That's certainly not what I want. I've attached a rewrite of your code that uses profiles to select which configuration is run. For instance: mvn -Phello clean mvn -Pgoodbye clean Or I can do both at once: mvn -Phello,goodbye clean Is there a way to accomplish this without profiles? Trevor http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.vocaro antrun 1.0 pom hello org.codehaus.mojo exec-maven-plugin print-hello clean exec echo hello goodbye org.codehaus.mojo exec-maven-plugin print-goodbye clean exec echo goodbye - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 16, 2008, at 5:24 PM, Todd Thiessen wrote: I believe there is. Plugin can have different executions. There is some documentation about that here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycl e.html#Plugins But that doesn't work for the exec plugin. I'd be grateful if someone could prove me wrong. and I believe the definitive guide has some examples too. No, in the book they always pass the exec arguments on the command line. See: http://books.sonatype.com/maven-book/reference/customizing.html#section-custom-exec But you still would have to bind it to a phase, which you don't want to do. I'm not trying to avoid anything. If binding to a phase would solve the problems, then I'd do it. But simply binding a plugin to a phase is not enough, for reasons I have shown. So I agree with you that Maven is definitely heavy weight if all you wish to do is execute an exe with different parameters each time. It doesn't do this nicely. You probably just want a simple script for that. Or I could just use profiles. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 16, 2008, at 2:54 PM, Todd Thiessen wrote: They are more powerful in the sense that you can still call any goal independantly But if I have two tasks implemented with AntRun, there's no way to call them independently because there's only one goal: run. I guess most of my problems boil down to the limitations of the AntRun plugin. Perhaps the doxia plugin would work? http://maven.apache.org/doxia/book/index.html That plugin is fine if you want to use DocBook as a source for Doxia, but it's not designed for stand-alone documentation created using DocBook and the DocBook XSL stylesheets. The Xslt task in Ant works great for that, though. Not sure what you are doing in your profile that solves your issue though. If you give some further info on this, perhaps some of the more experieced Maven users can provide you with a pure Maven solution. Let me use a different plugin as an example. Let's say I'm developing a desktop application, and it runs in two different modes depending on the command-line options. I don't want to keep typing in the same long string of options all the time, so I pickle them into two separate Ant targets, "mode1" and "mode2". Then I can run them like this: ant mode1 ant mode2 How would I accomplish this in Maven? There's the exec plugin, but it has only one goal (exec:java). There's no way to run the application in two different ways with just that one goal. Not without profiles, that is. With profiles, I can create two profiles, "mode1" and "mode2", and define an exec plugin in each one. Then I can run them like this: mvn -Pmode1 exec:java mvn -Pmode2 exec:java So there's an example where profiles have nothing to do with build portability and are playing the same role as Ant targets. If you wish to run something independently, you don't need ant or Maven for this. Run run the executable. Isn't that like saying Ant or Maven aren't necessary for compiling Java code because you can just run the javac executable? Doesn't make sense... Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 16, 2008, at 10:42 AM, Martin Höller wrote: You are doing it wrong. Maven has no targets like ant has. Maven has lifecylces [0] which is built of phases (e.g. 'compile', package', 'install'). Plugins are attached to phases and are executed whenever a phase is executed. Well, without profiles, I don't know how to do it right. For example, I use the AntRun plugin to invoke install4j, which builds installers for my artifact. Binding this to the deploy phase probably makes the most sense, but if I do that, the deploy goal of the deploy plugin also runs. There's no way to tell Maven to just run the install4j stuff. If, however, I split off the install4j stuff into an "install4j" profile and bind it to the package phase, then I can do: mvn -Pinstall4j package And suddenly Maven does exactly what I want: It runs install4j and nothing else. Without profiles, how can I accomplish this? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are Maven profiles like Ant targets?
On Dec 16, 2008, at 10:43 AM, Todd Thiessen wrote: You probably want to use a plugin. For instance you could use the DocBook plugin. http://maven-plugins.sourceforge.net/maven-sdocbook-plugin/index.html The sdocbook plugin does not work with Maven 2. I also tried the more recent docbook plugin: http://mojo.codehaus.org/docbook-maven-plugin/ But it's in a very alpha stage and lacks basic features (e.g. PDF generation). That's why I'm using the AntRun plugin; it gives me access to Ant's Xslt task for transforming DocBook. You will also want to get a better understanding of Maven's build lifecycle and undertand how lifecycles, phases and goals are related. It is more complex than ant targets but is also far more powerful. http://books.sonatype.com/maven-book/reference/lifecycle.html I'm familiar with the lifecycles, but it's strange you should say they are more powerful than Ant targets because they seem less powerful, at least when using the AntRun plugin. For example, my DocBook AntRun stuff is used for generating developer documentation, so binding it to any of the default lifecycle phases doesn't make sense. The site phase of the site lifecycle is probably the best place to put it, but then it gets tossed in with everything else in that phase. There's no way to run the DocBook stuff by itself; I have to run it along with everything else in the site phase. So in that sense, lifecycles are less powerful than Ant targets because they are more coarsely grained. I don't have the same control over what gets run. If, however, I put the DocBook stuff into a separate profile then suddenly I have that control. I don't know how else to get it without profiles. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Are Maven profiles like Ant targets?
I'm coming from the Ant world, where targets are fundamental. Need to generate the JavaDocs and a JAR? Write targets called "javadoc" and "jar" then do: ant javadoc ant jar In Maven, these particular tasks have built-in plugins, so there's no need to write a target. Instead you just invoke the plugin goal: mvn javadoc:javadoc mvn jar:jar But there are many scenarios in which no plugin is available. For instance, I use install4j to build an installer, and I use DocBook to translate XML into PDF. Accomplishing these tasks with the AntRun plugin is easy enough, but it's not clear how to actually invoke them. The Ant concept of a target does not exist in Maven. Maven does have profiles, however. I'm able to put the install4j stuff into a profile called "install4j" and the DocBook stuff into a profile called "docbook". Then I can do: mvn -Pinstall4j mvn -Pdocbook This works, but from an end-user standpoint it's a little confusing. For some things you invoke a plugin goal but for other things you invoke a profile. It's inconsistent. Also, the Build Profiles chapter of the Maven book mentions nothing about this use case. It only talks about profiles for the purpose of build portability. So... am I doing this right? Are profiles intended to play the role of Ant targets? Or is there some other mechanism for that? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Not happy with maven
On Nov 19, 2008, at 1:44 PM, Martin von Gagern wrote: I would much prefer some kind of lib directory, where I could simply drop the library and start using it, to see if it is fit for the job I want to use it for in the first place. You can accomplish that by specifying the dependency with a "system" scope. You'd tell Maven about your lib directory using . The maven POM seems to lack a clear concept of task order. This seems especially important in the packaging phase. Suppose I produce a jar which I want to pack200, jarsign, gpgsign, include in an assembly, and gpgsign that assembly again. Clearly order matters a lot. I've had the exact same concern. Anyone have an answer for this? Another aspect of this security issue is the fact that there seems to be no way to ask the user for a password for e.g. jarsigner and hand that to jarsigner by some means other than a command line argument. On a multi-user *nix machine, users can see what commands other users are running, and I don't like them seeing my keystore passphrase. One way to handle this is with the antrun plugin. You can use the input task to prompt for a password and assign it to a property: Why do I need to configure it again and again for every plugin that operates on source files, instead of specifying it once and for all, with the possibility to override it on a per-file and per-plugin basis if need be? Yes, I can have some common ancestor configure the plugins and use a common property name for the encoding, but this kind of hacks seems to go against the whole idea of POMs describing projects. I'm a little confused. You say you want to specify file encoding in one place, but you don't want to specify it in a common ancestor. How do you envision this working? And interdependence between artifacts (like one containing the other) are not expressed either. Isn't that what modules express? I guess I would prefer clean instructions, like these source files are processed by these build tools in order to produce these artifacts. But that is precisely what a POM is. It defines what source files are to be processed, what build tools to use, and the artifacts that will be produced. It may not be explicit, instead defined in a parent POM or the Super POM, but that's only to eliminate redundancy. You just have to learn how to read a POM file. So I'd like to compile all my code using the latest javac, but substutute the bootclasspath of a different Java API version when compiling the main project code, along with providing the appropriate -source and -target switches. Not possible in Maven, afaik. How about using the compiler plugin's bootclasspath compiler argument? Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does maven-compiler-plugin choose its defaults?
On Nov 18, 2008, at 4:50 PM, Stephen Connolly wrote: 1.3 Ah... There is indeed a file in the Maven sources, JavacCompiler.java, that sets -source to 1.3 and -target to 1.1. It is in a "bootstrap" package, but I assume it somehow propagates to maven-compiler-plugin as well. Thanks for the pointer. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How does maven-compiler-plugin choose its defaults?
On Nov 18, 2008, at 2:13 PM, Trevor Harmon wrote: I'm curious about the source and target settings. They're set to 1.4, but there's nothing in my POM that specifies 1.4. Oops, never mind about that, there was actually a parent POM that specified 1.4. So let me rephrase my question: If there's no explicit compiler version specified, which compiler version is used? Is it just whatever version of Java that Maven is running on? Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How does maven-compiler-plugin choose its defaults?
When I do "mvn help:effective-pom", it shows: maven-compiler-plugin 2.0.2 true 1.4 1.4 I'm curious about the source and target settings. They're set to 1.4, but there's nothing in my POM that specifies 1.4. That means the plugin is somehow defaulting to 1.4 automatically. However, I looked in Maven's conf/settings.xml, and there's nothing there either. How exactly does the compiler plugin arrive at this default value? Thanks, Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sharing modules among multi-module projects
On Nov 13, 2008, at 5:26 PM, Wayne Fay wrote: Bear in mind that it is not sufficient to look at the file timestamps in target vs source and say "target files are all newer than source, therefore no changes" due to the possibilities of changes coming in via dependencies (including transitive ones), changes in plugins (if they aren't locked down, or if they are snapshots), etc. A change in a dependency or plugin would mean a change in a pom.xml, right? So Maven could simply compare the dates of the artifact with the dates of the associated POMs. Part of your build may be to grab another jar (versioned as snapshot), unpack it, and use it during this project's build I hadn't thought of this possibility. Is it a normal Maven use case? I don't see why it would be necessary. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sharing modules among multi-module projects
On Nov 13, 2008, at 1:23 PM, Wayne Fay wrote: I would tend towards the first one if you require both projects to "detect when a shared module is out-of-date" as you have stated. That's actually the approach our team is using now. The problem is that we've got quite a large number of projects. Something like this: \- Simple Parent Project +- Simple Weather API +- Simple Web Application Project +- Simple Web Application Project 2 +- Simple Web Application Project 3 +- ... +- ... +- Simple Web Application Project 17 And so when we do "mvn install" on the parent project, Maven goes through every module and does an install on it, copying the JAR to the local repository. This takes a lot of time, even if there's only one source code change. Perhaps something like this would work better: \- Simple Parent Project (does not include module definitions, only repository and SCM info) \- Libraries (specifies each child as a module) +- Simple Weather API +- Some Other API +- Yet Another API \- Applications (no module definitions) +- Simple Web Application Project +- Simple Web Application Project 2 +- Simple Web Application Project 3 With this approach, each application project would declare "Libraries" as a module. I could then do "mvn install" on an application project, and it would build only the Libraries module (with all of its children) and the one application, filtering out the rest. The only problem is that as the number of libraries grows, so too does the build time, even if the application only depends on one or two libraries. So I'm back to the same issue of the build taking too long as Maven goes through each module and does an "install" on it. But then, this seems like a Maven bug. Why go through the install process for a project if its source code hasn't changed? Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validate POM
On Nov 13, 2008, at 11:00 AM, Jason van Zyl wrote: mvn validate As a follow-up question, I am finding many cases where a seemingly invalid POM is not being flagged as invalid. For example: ... foo.bar ... This is clearly invalid because the exclusions section should only have exclusion tags as children. But "mvn validate" doesn't complain about it. In fact, you can put any known POM tag in the exclusions section and it will still validate. Is the XSD wrong? Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is pluginManagement necessary?
On Nov 13, 2008, at 10:40 AM, Nick Stolwijk wrote: Yes, take a look at multi module builds. The pluginManagement section will be valid for all child modules instead of only this module. This does not seem to be true. In the Chapter 6 example, if you remove the pluginManagement section, leaving only the plugins section, the compiler plugin configuration is still propagated to the children. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sharing modules among multi-module projects
There's an example in Chapter 6 of "Maven: The Definitive Guide" that shows how to set up and use a multi-module project. It's structured like this: \- Simple Parent Project +- Simple Weather API +- Simple Web Application Project With this setup, you can do "mvn install" on the parent project, and any out-of-date source code in any child project will automatically be compiled. So instead of running "mvn install" on each child, you can do it just once on the parent. Nice! However... What if you now want to create a new web application project? Let's say this new web application is completely independent of the old one, but it still uses Simple Weather API. I guess one approach is to create a new multi-module project like this: \- Simple Parent Project 2 +- Simple Web Application Project 2 Then simply add a dependency on Simple Weather API. But the problem here is that if you change the source code in Simple Weather API, running "mvn install" on Simple Parent Project 2 won't compile the change! You have to switch to Simple Weather API, run "mvn install", and then return to Simple Parent Project 2. This is really annoying, especially if you have more than one shared module. Is there any way to set up multi-module projects so that they can share a module, and both projects can detect when that module's source code is out-of-date? Thanks, Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is pluginManagement necessary?
I'm really confused about the pluginManagement section. It seems arbitrary and unnecessary. For instance, in the Chapter 6 example from "Maven: The Definitive Guide", there is the following declaration: org.apache.maven.plugins maven-compiler-plugin 1.5 1.5 Without this declaration, the project fails to compile because the source code uses Java 1.5 syntax. However -- and this is the part that baffles me -- if you simply remove the pluginManagement tags (leaving the plugins section intact), it still works perfectly! Can someone point me to an example where pluginManagement actually serves a purpose? Thanks, Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validate POM
The Maven 1.x documentation describes a way to validate a POM file: http://maven.apache.org/maven-1.x/plugins/pom/validation.html This uses the XML schema to determine whether the POM is well-formed. However, the "pom" plugin apparently no longer exists in Maven 2.x. In that case, how does one validate a POM file? Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location of changelog, installer files?
On Nov 10, 2008, at 6:28 PM, Chris wrote: Where in the standard maven directory layout should I put the changelog for my app (changelog.txt)? I'm not sure about a standard, but we put internal documentation in src/main/doc/development. Where should I put files that are used only by the installer? These are files that are needed at build time, but shouldn't be distributed. They include the XML file that tells the install tool how to build the release, and a few JPGs used on the installer screens. We use the Assembly plugin and install4j to build an installer, and we put the Assembly descriptors into src/assembly and the install4j files (e.g., icons) into src/install4j. Where should I put the script used by our obfuscator? We use Zelix KlassMaster and have a src/zkm directory. It looks like files like readme.txt and license.txt go in the root of the project, but I don't feel comfortable putting files other than changelog.txt there. Perhaps in src/test/resources? We put end-user documentation into src/main/doc/deployment. Again, I don't know if these are the "standard" conventions; it's just what we use. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How do I bind AntRun plugin to Assembly plugin?
I've got a POM that packages up my code using the Assembly plugin, then it does some custom processing of the assembled code using the AntRun plugin. To accomplish this, I've got both plugins bound to the package phase so that they always run together. This works okay, except that whenever I do "mvn install" the plugins get executed. I only want them to run if I do "mvn assembly:assembly". The Assembly plugin handles this, of course, but the AntRun plugin is another matter. It has to be bound to a lifecycle, otherwise it doesn't run. Any suggestions on how to handle this? Thanks, Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No Cobertura, please
On Nov 3, 2008, at 12:42 PM, Oleg Gusakov wrote: Strange, but true analogy - quantum cryptography is so interesting because of the same principle: "we cannot observe a phenomena without changing it" Otherwise known as the Heisenbug: http://en.wikipedia.org/wiki/Unusual_software_bug Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding dependency of jars for an existing project
On Oct 22, 2008, at 10:12 AM, antnewbie wrote: do i have to give dependency for all jars? You need to provide dependency information for all JARs that you do not develop yourself. For some jars i don't know the version(how do i get the version?) You can find version numbers here: http://www.mvnrepository.com/ Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recommended project structure.
On Oct 16, 2008, at 12:59 PM, Raphaël Piéroni wrote: For a good idea of a multi module project, you could refer to platina: http://platina.svn.sf.net/svnroot/platina/platina-archetype/ Doesn't seem to be anything there. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
