Re: Adding to Books on Maven?
Hello, you may be interested in adding Agile ALM (http://www.manning.com/huettermann/) as well. It covers Maven in many different chapters. In the book, Maven is used as a backbone to set up a comprehensive application lifecycle management. The book provides both the big picture and a lot of details. Michael Am Montag, den 28.10.2013, 00:17 +0100 schrieb Olivier Lamy ol...@apache.org: done. On 27 October 2013 21:13, Russell Gold wrote: Thanks, Olivier. You could use this image. And it actually covers Maven 3.0.4 and above. Thanks, Russ On Oct 27, 2013, at 3:34 AM, Olivier Lamy wrote: done. Let us know if you need something else. (images?) On 26 October 2013 02:29, Russell Gold wrote: How does one get added to the list of available Maven publications on the site (http://maven.apache.org/articles.html [4])? - Author, Getting Started with Apache Maven Come read my webnovel, Take a Lemon , and listen to the Misfile radio play ! -- Olivier Lamy Ecetera: http://ecetera.com.au [8] http://twitter.com/olamy [9] | http://linkedin.com/in/olamy [10] - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org [11] For additional commands, e-mail: users-h...@maven.apache.org [12] - Author, Getting Started with Apache Maven Come read my webnovel, _Take a Lemon _, and listen to the Misfile radio play ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
file based mirror
Hello, as the mirror in the settings.xml, is it possible to reference a file based repository as URL? How to define it? Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Lightweight maven-releases, or an alternative to the maven-release-plugin
Hello, if interested: the topic of lightweight maven releases is discussed in DevOps for Developers, Apress, Chapter 8. Cheers, Michael Hello there, I. find prepare and perform quite heavyweight my self. After prepare did build everything successfully, it throws away everything, just tags the source and starts over again during perform. prepare already checks with scm means, that there are no modifications and in my experience tagging is the most harmless operation in the whole process (well, would I still use CVS that could be different). So running prepare with prepareGoals set to -DperformRelease=true clean deploy does what *I* want. - checks I have everything in SCM - does modify POMs for release. - deploys to staging - only on success of this tags the sources - go back to SNAPSHOT. git and svn (when not doing the strange remoteTagging) are capable of tagging always. Worst thing that might happen: bad stuff in staging for a short time. Regards Mirko -- Sent from my mobile On May 1, 2013 9:15 PM, Robert Scholte rfscho...@apache.org wrote: Graham, well said. Although the pom.xml is the easiest way to discover the version, it is not the best location, since it would require a commit. The solution must be found in a generated file which will be added to the artifact during packaging. Here you could add a timestamp or revision. Robert Op Wed, 01 May 2013 12:44:19 +0200 schreef Graham Leggett minf...@sharp.fm: On 30 Apr 2013, at 11:21 PM, Roger Brechbühl rotscher...@gmail.com wrote: Maybe somebody is interested in how a release could be built in a more lightweight and safe way than with the maven-release-plugin. Especially recommended for nightly releases. It's not yet released, but basically fully working: *mvn clean install -Dversion.override=1.2.3-S-5* https://github.com/rotscher/**emerging/tree/version.** override-with_maven_install-2.**4https://github.com/rotscher/emerging/tree/version.override-with_maven_install-2.4 Maven has a very clear definition of a release, being an artefact that can traced back to the precise code via a tag, and a build that can be repeated. This is as opposed to a snapshot, which has no well defined origin. You might approach this two ways, you might create nightly snapshots and have them deployed somewhere suitable, using mvn deploy. Alternatively if you want to create proper nightly releases (in the maven sense), you could feed a custom version number into the release plugin to represent your release, but this starts to smell like that's what a snapshot is for. Regards, Graham -- --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release:prepare
the trick for such scenarios is easy: don't use the release-plugin. Am Samstag, den 05.01.2013, 13:29 +0100 schrieb Sundeep Reddy sundeep.i...@gmail.com: Hi All, The maven release:prepare does the following things: release: prepare – Performs a number of operations - Checks to make sure that there are no uncommitted changes. - Ensures that there are no SNAPSHOT dependencies in the POM file, - Changes the version of the application and removes SNAPSHOT from the version. ie 1.0.3-SNAPSHOT becomes 1.0.3 - Run project tests against modified POMs - Commit the modified POM - Tag the code in Subversion - Increment the version number and append SNAPSHOT. ie 1.0.3 becomes 1.0.4-SNAPSHOT - Commit modified POM Is there way where we could skip the last 2 steps i,e increment of the version number and appending the SNAPSHOT . In a way just want to convert the snapshot to a release,no further development version. Thanks Sundeep - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: access password in settings.xml
Hi Mirko,
thanks! What are the necessary imports and the POM dependencies for that?
Thanks.
Michael
Hello Michael,
reading your Agile ALM book right now :-):
Here is an example how to get all servers with password decrypted:
public class MyMojo extends AbstractMojo {
/**
* Maven settings.
*/
@Component
private Settings settings;
/**
* The decrypter for passwords.
*/
@Component
private SettingsDecrypter settingsDecrypter;
/**
* Returns the list of servers with decrypted passwords.
*
* @return list of servers with decrypted passwords.
*/
ListServer getDecryptedServers() {
final SettingsDecryptionRequest settingsDecryptionRequest =
new DefaultSettingsDecryptionRequest();
settingsDecryptionRequest.setServers(settings.getServers());
final SettingsDecryptionResult decrypt =
settingsDecrypter.decrypt(settingsDecryptionRequest);
return decrypt.getServers();
}
}
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
https://twitter.com/mfriedenhagen
On Fri, Aug 24, 2012 at 11:36 AM, Michael Hüttermann
mich...@huettermann.net wrote:
Hello,
how can I (e.g. programmatically, in an own Maven plugin) access the
serverpassword element of settings.xml, to re-use the value. Is
there
any chance to do so?
Thanks!
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
repositories in settings.xml/POM
Hello fellows, why is it recommended to configure the repositories in the settings.xml and not in the POM? I'm afraid I've forgotten the reason. Thanks for your answer! Cheers Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: repositories in settings.xml/POM
awesome, thanks! http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ /Anders On Mon, Aug 13, 2012 at 11:02 PM, Michael Hüttermann mich...@huettermann.net wrote: Hello fellows, why is it recommended to configure the repositories in the settings.xml and not in the POM? I'm afraid I've forgotten the reason. Thanks for your answer! Cheers Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Documentation for Maven3
Hi Sascha, probably it's a good start for you to read documentation about Maven (2/3) in general, particularly what are Maven's concepts, and how/where you can configure the build respectively single plug-ins. For instance, Sonatype's free books as well as Brett Porter's book are great. Regarding annotations, maybe you mean that you need to configure Maven to set the compiler level to Java 5+ to work with Java Annotations? You'll have to configure your project model with XML, unless you're going a Maven 3 multilingual way, e.g. scripting your POMs with Groovy, or you're working with OSGi, that case is a bit different too. Regards Michael -- Michael Hüttermann Java Champion Author of Agile ALM 0049(0)173.5373629 http://huettermann.net Am Mittwoch, den 22.06.2011, 10:35 +0200 schrieb Sascha Vogt sascha.v...@gmail.com: Hi all, as requested by Barrie starting a new thread. I'm new to maven and currently looking for some good reading. Is there any Maven3 documentation out yet? I already read Maven in 5 minutes, Getting started, Your first mojo and a couple of blogs. Now I specifically need to create a few new packaging types and I didn't find good resources on how to do that with Maven3 (I read somewhere that one can now use Java annotations instead of Javadoc ones). I currently have a first prototype using the Javadoc annotations and a copied/modified version of a plexus/components.xml which should resemble the JAR plugin instead of the packaging phase. Maybe I'm missing something, I hoped that there would be a more unintrusive way to hook oneself in the build-lifecycle. I for example didn't find any components.xml for the maven-jar-plugin (or I'm looking at the wrong places...). Any pointer would be really appreciated (even pointers to source code, I already looked into maven-jar, maven-ear and maven-war but they are all using the old? Javadoc annotations - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Checkstyle RegexpSingleline on XML files
Hello, I want to validate XML files, but the module description below only detects the false format pattern in Java files. Although also using the property fileExtensions additionally [1], I don't get my XML files validated. I'm using version 2.6 of the Maven checkstyle plugin and define and reference my configuration accordingly [2] (the checkstyle xml config is processed correctly except that the RegexpSingleline definition does not work). -- Maybe I'm a bit blind, how can I configure it to make it apply to XML files as well? Or should I better stick to a different checkstlye module? Thanks!!! module name=Checker module name=RegexpSingleline property name=severity value=warning / property name=format value=findme\s+$ / property name=message value=bug! / /module /module [1] http://checkstyle.sourceforge.net/config_regexp.html [2] http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/custom-checker-config.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Continuous Delivery and Maven
Hello fellows, perhaps it is interesting for you that the book Agile ALM [1], illustrates strategies and tools (especially Maven). I'm also covering aspects that are discussed here in this thread. [1] http://huettermann.net/alm Cheers Michael -- -Java Champion- mich...@huettermann.net http://huettermann.net http://twitter.com/huettermann - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Write Maven Books
Hello, Am Mittwoch, den 07.07.2010, 14:00 +0200 schrieb Ron Wheeler A book on the subject will also have to touch on IDE integration, source management, maven repositories, continuous integration and other development areas. I would like to see a book targeted at the 80% of developers who should be using these tools out of the box with no custom plug-ins or custom setups. Discussing the odd-ball cases would only make Maven more confusing. You may find Agile ALM very useful: http://www.manning.com/huettermann/ Maven is a major, leading tool in this book. The intention of this book is pretty similar to what you've described. Regards Michael -- -Java Champion- mich...@huettermann.net http://huettermann.net http://twitter.com/huettermann - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding jars to the compiler plugin's classpath
yes, have a look on the site I've pointed to: http://maven.apache.org/pom.html#Extensions You just need to define an extension (or multiple) inside the build element build extensions extension .. You must reference the classpath extension (i.e. the artifact) the Maven way, like you would do with dependencies. With other words, the referenced artifact must be Mavenized. Michael Hi Michael, It seems that extensions is what I'm looking for. Unfortunately I haven't found any info about how to create (?) one. Do you know where can I find more info? :) Many thanks, -Alex On Wed, May 5, 2010 at 10:53 PM, Michael Hüttermann mich...@huettermann.net wrote: you can use Maven's extensions to extend the build classpath http://maven.apache.org/pom.html#Extensions Is there a way to add jars to the compiler plugin's classpath without actually specifying as dependencies. For example, I need to specify to the Java compiler extra jars in certain directory. Since the number of jars is huge, and that might change in the future, I'd like to just say, all the *.jar files in directory 'foo'. Many thanks in advance, -Alex - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding jars to the compiler plugin's classpath
you can use Maven's extensions to extend the build classpath http://maven.apache.org/pom.html#Extensions Is there a way to add jars to the compiler plugin's classpath without actually specifying as dependencies. For example, I need to specify to the Java compiler extra jars in certain directory. Since the number of jars is huge, and that might change in the future, I'd like to just say, all the *.jar files in directory 'foo'. Many thanks in advance, -Alex - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RCP
Hello, what is the recent recommended way to build RCP apps? Is a how-to available which is up-to-date ? Thanks in advance. Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
file system storage
Hello, why is Maven storing the stuff in the file system everywhere? Locally, on the developers' desktop it is ok. Centrally, why not in a common version control system? What are the design decisions for that? Thank you. Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: file system storage -- why?
Hello, thanks for answering, but the question is not answered, and I want add some further thoughts. One common pattern is not to store derived artifacts. Although I understand Maven pretty good believe me that and like its approach, I think about the design decision why it is the way it is. Why not put all artifacts into the same version control system you already use while managing your sources? Why storing the artifacts at all, if you can reproduce them at any time (having the sources and the build system). I'm just collecting arguments. :-) With everywhere I mean everywhere Maven runs it stores the artifacts in the file system. I know that you can configure where the repository is located, physically. With stuff I mean all artifacts managed by Maven, pardon me my casual wording. Michael Hi Michael, why is Maven storing the stuff in the file system everywhere? Locally, on the developers' desktop it is ok. You mean /home/username/.m2/repository this is the usual location for all artifacts which are used once...the intention to increase speed during building...which is not everywhere and not on the desktoponly per user base(Unix, Windows and Mac OS as well). If you really like to change that behaviour you can make a configuration to use a system wide storage...instead of a user based storage...but this would pin you on a particular system. Centrally, why not in a common version control system? It might be a possible solution, but the setup is very simple without such an requirement...and would usually reduce build time On the other hand you can use a simple Web-DAV Setup for a deployment area which uses a Version Control tool to store the deployed artifacts (may be SVN etc.). And one other thought is coming into my mindyour build should be repeatable if you do things right (pinning version of Plugin etc.) it shouldn't matter where you build... What are the design decisions for that? I can only assume what the intentions are... Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven/Nexus/Hudson/EC2
that is a good point. What do you think about running a build server in the Cloud while having the repo manager locally ? While seeing the benefits of services and also of using the cloud in general, I'm having a hard time ignoring the fact that I would like to have my repo manager locally. One great benefit of a repo manager is improved speed when downloading artifacts, which I wouldn't get when it's hosted outside of my LAN. Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven/Nexus/Hudson/EC2
What could be a practical scenario in the CI context for Clouding ? Michael On Thu, Oct 8, 2009 at 4:52 AM, Anders Hammar and...@hammar.net wrote: Yes, I was thinking about that one. Didn't really come to a good conclusion. Pros: * Easy to scale out * Easy to start up (you don't have to buy the hardware etc) Cons: * Security (if you need to retrieve the code and you don't want to have your version management system publicly available) * If the repo manager is locally and the build server is externally, retrieving artifacts will be slower. However, possibly not a big issue unless you need to squeeze out that extra performance (time wise). * Cost (?) What I'm thinking is that it could be an easy way to get started, but as your build server(s) is most likely something you want for a long time and it will be working constantly, I think it might make more sense having it locally on your own hardware. It think it will be far more expensive to have it in the cloud compared to this. However, I don't have any figures to back this up, it's just my guess. Anyone else having any thoughts? I'm thinking along the same lines. The virtual cloud instances are good for sporadic use but aren't as cost effective for around the clock cpu / disk io that you would see from a CI system. Also a CI system puts a heavy load on your repository (push and pull) so it needs to be near the repo. Having your repo in the cloud invalidates many of the benefits, namely proxying and caching that speeds up your builds and provides you the ability to continue working when your network is unstable. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven/Nexus/Hudson/EC2
Hello, do you plan to continue the work in the context nexus/hudson/ec2 you kicked off and described here: http://www.sonatype.com/people/2009/06/nexus-open-source-and-hudson-on-ec2/ E.g. are you planning to provide new Maven versions in ec2 continuously, to add more convenience features, .. or similar things ? Thank you. Best regards Michael -- mich...@huettermann.net http://huettermann.net - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RELEASE and branches
Hello experts, how do you set up the process if you use RELEASE for a dependency in a POM, and work with VCS branches ? What is your best practice? Probably a branch will have to adress another, older version of an artifact, actually it has to adress a stable, tagged version. What happens if on HEAD you use new versions of dependencies (so a new version for RELEASE), ... do you adjust all of your branches to remove the RELEASE token and enter a dedicated version? Isn't that a nightmare ? Thanks !! Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RELEASE and branches
ok, I see, thanks! There is another concept using a generic version: snapshots. What do you do with your SNAPSHOTs while branching then? Do you go through all your POMs and dependencies replacing the snapshot token with the real snapshot version including timestamp? You can say ok, I will never use RELEASE but you want to use the snapshot mechanism in the daily work for sure I guess. What's your strategy here while branching ? Thanks for your time !!! Michael 2009/4/22 Michael Hüttermann mich...@huettermann.net Hello experts, how do you set up the process if you use RELEASE for a dependency in a POM, and work with VCS branches ? you stop using RELEASE for a dependency. RELEASE corresponds to the last released version... so if you release, in order 1.0.0 1.0.1 1.1.0 1.1.1 2.0.0 1.0.2 Then RELEASE will correspond to 1.0.2 as that was the last version released. The solution is to use version ranges, i.e. work on the 1.0.x branch would depend on [1.0.0,1.1.0-!) that is any version greater than or equal to 1.0.0 and less than 1.1.0-! (which thanks to the joys of ascii sorting means that you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less than 1.1.0) Of course version ranges only work if you follow maven's rules for version numbering... if you cannot follow maven's (some would say slightly strange) version numbering scheme you will need to do some manual work... to help automate the manual work, you'll probably end up using versions-maven-plugin and specifying the version using a property. What is your best practice? Probably a branch will have to adress another, older version of an artifact, actually it has to adress a stable, tagged version. What happens if on HEAD you use new versions of dependencies (so a new version for RELEASE), ... do you adjust all of your branches to remove the RELEASE token and enter a dedicated version? Isn't that a nightmare ? I think you will realise from my earlier comment that there is *no way in hell* that you would use RELEASE. FYI, the LATEST and RELEASE versions were initially more for use in specifying plugin versions... but they are so problematic that everyone pretty much avoids them -Stephen Thanks !! Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RELEASE and branches
starting at lowest dependencies and work the way ... having a pretty big build system this sounds like a nightmare. Just only using the maven release plugin on the top level isn't enough right ?! Michael We use snapshot for all versions while developing then when release time comes we release (maven release plugin) each project, starting at the lowest dependency and work our way up to the top. The release plugin will automatically update each project to the next snapshot version, as well as SCM tagging, etc. On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann mich...@huettermann.net wrote: ok, I see, thanks! There is another concept using a generic version: snapshots. What do you do with your SNAPSHOTs while branching then? Do you go through all your POMs and dependencies replacing the snapshot token with the real snapshot version including timestamp? You can say ok, I will never use RELEASE but you want to use the snapshot mechanism in the daily work for sure I guess. What's your strategy here while branching ? Thanks for your time !!! Michael 2009/4/22 Michael Hüttermann mich...@huettermann.net Hello experts, how do you set up the process if you use RELEASE for a dependency in a POM, and work with VCS branches ? you stop using RELEASE for a dependency. RELEASE corresponds to the last released version... so if you release, in order 1.0.0 1.0.1 1.1.0 1.1.1 2.0.0 1.0.2 Then RELEASE will correspond to 1.0.2 as that was the last version released. The solution is to use version ranges, i.e. work on the 1.0.x branch would depend on [1.0.0,1.1.0-!) that is any version greater than or equal to 1.0.0 and less than 1.1.0-! (which thanks to the joys of ascii sorting means that you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less than 1.1.0) Of course version ranges only work if you follow maven's rules for version numbering... if you cannot follow maven's (some would say slightly strange) version numbering scheme you will need to do some manual work... to help automate the manual work, you'll probably end up using versions-maven-plugin and specifying the version using a property. What is your best practice? Probably a branch will have to adress another, older version of an artifact, actually it has to adress a stable, tagged version. What happens if on HEAD you use new versions of dependencies (so a new version for RELEASE), ... do you adjust all of your branches to remove the RELEASE token and enter a dedicated version? Isn't that a nightmare ? I think you will realise from my earlier comment that there is *no way in hell* that you would use RELEASE. FYI, the LATEST and RELEASE versions were initially more for use in specifying plugin versions... but they are so problematic that everyone pretty much avoids them -Stephen Thanks !! Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
ejb manifest -- strip version numbers of dependencies
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
ejbVersion2.1/ejbVersion
generateClientfalse/generateClient
archive
manifest
addClasspathtrue/addClasspath
classpathLayoutTypecustom/classpathLayoutType
customClasspathLayout${artifact.artifactId}/customClasspathLayout
/manifest
/archive
/configuration
/plugin
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
clean scm:update|deploy on a parent POM, modules?
Hello, I have the following structure /root/moduleA/ /root/moduleB/ /root/moduleC/ and the following CruiseControl snippet (I skipped the time and mvnhome-attributes here): maven2 pomfile=/root/moduleB/pom.xml goal=clean scm:update|deploy/ (the issue is not depending on CruiseControl though) The addressed /root/moduleB/pom.xml is of package type POM referencing a bunch of other modules especially /root/moduleA/ and /root/moduleC/ /root/moduleB/pom.xml also contains the elements scmconnection.../connectiondeveloperConnection.../developerConnectionurl.../url. The connection references the /root/ in my Subversion. I checked out the /root/ from Subversion to my build machine including ./moduleA, ./moduleB, ./moduleC to do a mvn deploy after updating the sources there. So with other words, before running a mvn deploy I want to update my whole root level /root/* on the build machine with all its modules. Unfortunately it looks like the modules are not updated accordingly. With my setting, obviously only the /root/moduleB/ is updated. Is this possible? How can I customize the setting that /root/ is updated completely ? Thanks for your time! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: clean scm:update|deploy on a parent POM, modules?
or with other words: how can I update a checked out folder completely before calling a mvn deploy on a single module inside the whole structure? Alternatively: how can I checkout a complete folder before? Doing an update or a checkout is not a difference here. What is the recommended way? As explained below .. there are some pitfalls .. Thanks !! Michael Hello, I have the following structure /root/moduleA/ /root/moduleB/ /root/moduleC/ and the following CruiseControl snippet (I skipped the time and mvnhome-attributes here): maven2 pomfile=/root/moduleB/pom.xml goal=clean scm:update|deploy/ (the issue is not depending on CruiseControl though) The addressed /root/moduleB/pom.xml is of package type POM referencing a bunch of other modules especially /root/moduleA/ and /root/moduleC/ /root/moduleB/pom.xml also contains the elements scmconnection.../connectiondeveloperConnection.../developerConnectionurl.../url. The connection references the /root/ in my Subversion. I checked out the /root/ from Subversion to my build machine including ./moduleA, ./moduleB, ./moduleC to do a mvn deploy after updating the sources there. So with other words, before running a mvn deploy I want to update my whole root level /root/* on the build machine with all its modules. Unfortunately it looks like the modules are not updated accordingly. With my setting, obviously only the /root/moduleB/ is updated. Is this possible? How can I customize the setting that /root/ is updated completely ? Thanks for your time! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error: 'null' for project unknown
Hello Maven gurus, I'm wondering if the issue I described below never occured before?! Does anyone have a hint for me how to solve that issue? Thanks Michael Hüttermann schrieb: Hello, I'm doing a mvn clean inside a project and get the message: Fatal Error Error building POM (may not be this project's POM) Project ID: unknown Reason: Failed to build model from file: C:\...\pom.xml. Error: 'null' for project unknown The Trace delivers an error at org.apache.DefaultMaven.getProjects(DefaultMaven.java:378) Strange is that on one machine the project can be cleaned as expected and on the other the problem above arises. The system environments are the same, i.e. other projects can be build without any problems. What can be the problem? When does the described error pop up normally? Any experiences? Thank you! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Error: 'null' for project unknown
Hello, I'm doing a mvn clean inside a project and get the message: Fatal Error Error building POM (may not be this project's POM) Project ID: unknown Reason: Failed to build model from file: C:\...\pom.xml. Error: 'null' for project unknown The Trace delivers an error at org.apache.DefaultMaven.getProjects(DefaultMaven.java:378) Strange is that on one machine the project can be cleaned as expected and on the other the problem above arises. The system environments are the same, i.e. other projects can be build without any problems. What can be the problem? When does the described error pop up normally? Any experiences? Thank you! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Archiva and Maven 2.0.9, defect POM
Hello, I use Maven 2.0.9 and Archiva 1.1.1. In my environment the central proxy repository Archiva has a defect entry for \internal\org\apache\maven\maven\2.0.9. After some manual and suboptimal work there only dummy data garbage is existing in that folder. Actually after installing Archiva the folder was not existing at all. OK, now I have issues with that defect entries for 2.0.9, and I removed the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not sure how wise this was, but if I trigger a mvn install or if I browse Archiva via web interface, I still get and see the old and corrupt 2.0.9 version. So the question is, how can I refresh Archiva that it will deliver the right 2.0.9 version for me? The correct version I see under http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? Thank you for your time!!! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Archiva and Maven 2.0.9, defect POM
Thanks, but migrating the tooling is not a solution strategy for us. Any ideas to solve that issue? Thanks !!! We had similar issues with archiva. These type of issues were resolved when we went to http://nexus.sonatype.org/ -Original Message- From: Michael Hüttermann [mailto:mich...@huettermann.net] Sent: Monday, February 02, 2009 11:45 AM To: users@maven.apache.org Subject: Archiva and Maven 2.0.9, defect POM Hello, I use Maven 2.0.9 and Archiva 1.1.1. In my environment the central proxy repository Archiva has a defect entry for \internal\org\apache\maven\maven\2.0.9. After some manual and suboptimal work there only dummy data garbage is existing in that folder. Actually after installing Archiva the folder was not existing at all. OK, now I have issues with that defect entries for 2.0.9, and I removed the whole folder \internal\org\apache\maven\maven\2.0.9 from disc. I'm not sure how wise this was, but if I trigger a mvn install or if I browse Archiva via web interface, I still get and see the old and corrupt 2.0.9 version. So the question is, how can I refresh Archiva that it will deliver the right 2.0.9 version for me? The correct version I see under http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.9/ ? Thank you for your time!!! Best regards Michael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Compilation failure .. symbol: method lookup(java.lang.String) -- EJB 2
I'm just wondering: no one did ever compile an EJB 2 project with Maven 2 ??? Michael Hüttermann schrieb: Hello, I have an EJB 2.1 project (the relevant POM snippets below). If I want to compile it I get a Build Failure: Compilation failure .. symbol: method lookup(java.lang.String) location: interface javax.ejb.SessionContext Why ? What is wrong with the POM ? How do I have to reference the J2EE spec correctly ? Thank you very much ! project xmlns=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; modelVersion4.0.0/modelVersion groupIdaaa/groupId artifactIdbbb/artifactId version1.0-SNAPSHOT/version packagingejb/packaging build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId configuration generateClienttrue/generateClient /configuration /plugin /plugins /build dependencies ... dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee_1.4_spec/artifactId version1.1/version scopeprovided/scope /dependency /dependencies ... /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compilation failure .. symbol: method lookup(java.lang.String)
thanks!!!, but it does contain the missing class javax.ejb.SessionContext. I'm not sure when to use the Geronimo artifact I used or a geronimo-spec-ejb. Anyway, my j2ee geronimo dependency does contain the SessionContext artifact ... why does compiling fail nevertheless?? :-( Using a javax.ejb.SessionContext is necessary for all EJB 2 applications .. so I still wonder what others exactly use as J2EE dependency for compiling EJB 2 projects with Maven 2 ?? Michael Wayne Fay schrieb: symbol: method lookup(java.lang.String) location: interface javax.ejb.SessionContext dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee_1.4_spec/artifactId version1.1/version scopeprovided/scope /dependency Go into your Maven repo cache under ~/.m2/repository and find the jar file corresponding to this artifact. Open it with a zip file tool like WinZip etc. Dig around in the jar to confirm it has the class file corresponding to the interface mentioned in the error. I would be willing to bet it does not have the class. You probably need to use geronimo-spec-ejb or another similar artifact instead.
Compilation failure .. symbol: method lookup(java.lang.String)
Hello, I have an EJB 2.1 project (the relevant POM snippets below). If I want to compile it I get a Build Failure: Compilation failure .. symbol: method lookup(java.lang.String) location: interface javax.ejb.SessionContext Why ? What is wrong with the POM ? How do I have to reference the J2EE spec correctly ? Thank you very much ! project xmlns=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; modelVersion4.0.0/modelVersion groupIdaaa/groupId artifactIdbbb/artifactId version1.0-SNAPSHOT/version packagingejb/packaging build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ejb-plugin/artifactId configuration generateClienttrue/generateClient /configuration /plugin /plugins /build dependencies ... dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee_1.4_spec/artifactId version1.1/version scopeprovided/scope /dependency /dependencies ... /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Installing a checked-out JAR, not the packaged one
Hello experts, during a build lifecycle I want to checkout a whole eclipse project from SVN which also contains an already available and packaged JAR. I copy this JAR from outside the checkout-directory to the root of my Maven project. This copied jar must be distributed by install/deploy. The Maven project itself neither contains business classes nor contains test classes, it is just a wrapper for the checked-out JAR. How would you archieve this? One try you can see below. The checked-out JAR is placed correctly to the root folder of my Maven project but the wrong jar is installed. mvn install installs the empty jar (the project has no classes) describing my Maven project itself. Why? How can I install/deploy the final checked-out JAR (only)? Thanks ?xml version=1.0 encoding=UTF-8? project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion artifactIdabc/artifactId packagingpom/packaging version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration finalNametodelete/finalName /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId executions execution phasecompile/phase configuration connectionUrlcheck the eclipse project out .../connectionUrl scmVersion.../scmVersion scmVersionType.../scmVersionType /configuration goals goalcheckout/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution phasepackage/phase configuration tasks echocopy just the jar from outside the checkout-folder to the Maven-project root directory/echo copy .../ /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin /plugins /pluginManagement /build /project Thanks Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing a checked-out JAR, not the packaged one
Thanks! Isn't there any way to jump into the lifecycle and prevent Maven to deploy the packaged jar ?? Or: to prevent Maven to package the jar? Use build-helper plugin to attach the checked-out jar to your build, so it is installed and deployed alongside other artifacts. This will not, however, prevent Maven from deploying your packaged jar as well. Wayne On Tue, Oct 7, 2008 at 5:37 AM, Michael Hüttermann [EMAIL PROTECTED] wrote: Hello experts, during a build lifecycle I want to checkout a whole eclipse project from SVN which also contains an already available and packaged JAR. I copy this JAR from outside the checkout-directory to the root of my Maven project. This copied jar must be distributed by install/deploy. The Maven project itself neither contains business classes nor contains test classes, it is just a wrapper for the checked-out JAR. How would you archieve this? One try you can see below. The checked-out JAR is placed correctly to the root folder of my Maven project but the wrong jar is installed. mvn install installs the empty jar (the project has no classes) describing my Maven project itself. Why? How can I install/deploy the final checked-out JAR (only)? Thanks ?xml version=1.0 encoding=UTF-8? project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion artifactIdabc/artifactId packagingpom/packaging version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration finalNametodelete/finalName /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId executions execution phasecompile/phase configuration connectionUrlcheck the eclipse project out .../connectionUrl scmVersion.../scmVersion scmVersionType.../scmVersionType /configuration goals goalcheckout/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution phasepackage/phase configuration tasks echocopy just the jar from outside the checkout-folder to the Maven-project root directory/echo copy .../ /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin /plugins /pluginManagement /build /project Thanks Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing a checked-out JAR, not the packaged one
I setup a comprehensive integration build. One part of it is retrieving some legacy artifacts (which are not Maven-enabled) and deploy them into a proxy repository. I do not want to do this only a single time by hand, I want to do this continuously as part of the reproducable full-fledged enterprise build. Checking out the legacy artifact from SVN and all this stuff is pretty generic. Is this so odd? Would you deploy them one after the other by hand nevertheless? Michael There may be a way to accomplish this, but this is simply not a use case I've ever encountered myself, so I have no idea if its possible or how to do so. To be honest, I don't understand your use case here either. I would probably use install:install-file and deploy:deploy-file rather than what you are attempting. Wayne On Tue, Oct 7, 2008 at 12:25 PM, Michael Hüttermann [EMAIL PROTECTED] wrote: Thanks! Isn't there any way to jump into the lifecycle and prevent Maven to deploy the packaged jar ?? Or: to prevent Maven to package the jar? Use build-helper plugin to attach the checked-out jar to your build, so it is installed and deployed alongside other artifacts. This will not, however, prevent Maven from deploying your packaged jar as well. Wayne On Tue, Oct 7, 2008 at 5:37 AM, Michael Hüttermann [EMAIL PROTECTED] wrote: Hello experts, during a build lifecycle I want to checkout a whole eclipse project from SVN which also contains an already available and packaged JAR. I copy this JAR from outside the checkout-directory to the root of my Maven project. This copied jar must be distributed by install/deploy. The Maven project itself neither contains business classes nor contains test classes, it is just a wrapper for the checked-out JAR. How would you archieve this? One try you can see below. The checked-out JAR is placed correctly to the root folder of my Maven project but the wrong jar is installed. mvn install installs the empty jar (the project has no classes) describing my Maven project itself. Why? How can I install/deploy the final checked-out JAR (only)? Thanks ?xml version=1.0 encoding=UTF-8? project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion artifactIdabc/artifactId packagingpom/packaging version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration finalNametodelete/finalName /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-plugin/artifactId executions execution phasecompile/phase configuration connectionUrlcheck the eclipse project out .../connectionUrl scmVersion.../scmVersion scmVersionType.../scmVersionType /configuration goals goalcheckout/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution phasepackage/phase configuration tasks echocopy just the jar from outside the checkout-folder to the Maven-project root directory/echo copy .../ /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin /plugins /pluginManagement /build /project Thanks Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
