Re: Maven, Subversion and Eclipse issue
We set the following on each module's trunk: $ svn ps svn:ignore core target .project .classpath .settings On 9 May 2011 15:42, Refr Bruhl refr_br...@yahoo.com wrote: Team I've an issue with the m2 plugin using maven in conjunction with subversion. Since this crosses three platforms I thought I would try both the subversion and maven list to see if anyone has run across a similar issue and what the solution was. When maven dependency is enabled for an eclipse project the maven plugin will ensure the target subdirectory exists. This is usally a good thing. When the project is committed to subversion is when issues arise When a mvn clean is issued either thru the plugin or at the command shell the target directory is deleted. The eclipse maven 2 plugin will recreate the target subdirectory However subversion now complains the directory is out of sync. Most times the subversion plugin will not allow a force update. My current workaround is not to commit the entire project -- just subfolder components when I make updates. I'm thinking there is a cleaner solution to this. Using this method I am forced to use svn shell commands to create tags. The tag feature of the subversion plugin will not work unless all sub directories are commitable. has anyone else ran into this? If so what solutions or workarounds were found? Platform details below Eclipse: Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415 (c) Copyright Eclipse contributors and others 2005, 2010. All rights reserved. Visit http://www.eclipse.org/webtools Maven for Eclipse: M2 plugin by Sonatype 0.12.1.2011 Subversion for Eclipse Subversive byu Polarion 2.2.2 OS: Windows XP --Refr inn gra Wars are to be won with swords and spears, not with rice and salt. -- Uesugi Kenshin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Advantages of using a Repository Manager
Hi there, We have a slightly more open setup than you do where developers can add libraries _provided_ they're licensed under pre-approved business friendly licenses. Artifactory works excellently for us in that respect as it allows us to handle permissions at the right level, I also personally find the UI to be very intuitive and simple. We also use the repository to publish API libraries to our internal solutions teams and as an archive of customer deliverables quickly accessible by support. Repository Managers in general are very useful and Artifactory (power pack) in particular would get a recommendation from me. Kind regards Brian On 20 April 2011 13:23, Sony Antony sony.ant...@gmail.com wrote: Im trying to evaluate whether we should use a repository manager. Will somebody post at least a few of the advantages here Our project uses a list of pre approved ( and pre downloaded ) dependencies and plugins. --sony
Re: Multiple packages with different configuration files
I believe you can specify multiple executions. See: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Plugins I think you could use the EAR plugin for example with three separate executions, each with a configuration that excludes different files. Hope this helps. On 22 November 2010 23:19, ilya.may...@ubs.com wrote: Eric, Let me elaborate on the issue. I cannot use profiles as it will create only one distribution for me. I need to have the same compiled cod bundled with different config files for DEV/QA/PROD. Is there are any easy way to create 3 TAR files from one jar or war and include different sets of config files within each of them? How can I implement it with Assembly mojo? Thanks Ilya Mayzel Distributed Change Management UBS Financial Services Inc. 1000 Harbor Boulevard, 4th Floor Weehawken, NJ-07086 Phone: 201-352-7976 Email : ilya.may...@ubs.com -Original Message- From: Haszlakiewicz, Eric [mailto:ehas...@transunion.com] Sent: Monday, November 22, 2010 3:38 PM To: Maven Users List Subject: RE: Multiple packages with different configuration files Well those are some rather useless answers. JNDI will only do the job if you configure it that way. You need to get that configuration *into* tomcat somehow in the first place, regardless of whether you use JNDI or a properties file. To suggest some options for the original poster: There are several different options to choose which configuration gets used or included in a application package. One way, which I have used a fair amount, is to include all configurations, and have an environment variable that you set when you run that app that causes it to choose the right file. The exact method of doing this depends on exactly how your configuration is stored, but it might consist of things like having property references in spring config files, tomcat setenv.sh scripts that pass appropriate java options, or custom java code within your app that looks for the variable settings. On the other hand, if you want actual, separate application packages, each that only contains a single set of configuration options, well then you're back in the realm of how to get maven to do that for you. What I've done for this is use profiles with embedded ant tasks that copy the appropriate files into place. Then to build a dev environment you might do something like mvn -P dev package. Of course, you can use any other plugin config within a profile other than the ant plugin, such as having separate assembler plugin configs and include different configuration files that way. There's lots of way to do it; I'm not sure what the best one is. eric -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, November 22, 2010 1:03 PM To: users@maven.apache.org Subject: Re: Multiple packages with different configuration files JNDI will do the job on Tomcat. Ron On 22/11/2010 1:47 PM, Antonio Petrelli wrote: 2010/11/22ilya.may...@ubs.com: This app need to be packaged with different configuration files (server names/IP addresses) for Dev/QA/Prod environments. This kind of info are better put in the server. For example, for JBoss, you can create a .properties file and put it inside: jboss/server/yourserver/conf Everything in the conf directory is available in your classpath. Antonio - 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 Please visit our website at http://financialservicesinc.ubs.com/wealth/E-maildisclaimer.html for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven is a swamp
I really fail at understanding the XML rage. Yeah it's verbose. How's that a problem? We've had tools with auto complete, auto format and syntax highlighting for well over a decade, we also now have fairly robust GUIs too. If you're hand editing a 2000 line xml file in a green screen terminal you're doing the equivalent of using an abacus and I'm afraid you're not the user new tools ought to be aimed at. XML has a huge ubiquity value. It might not be the *best* tool for the job for each individual user but it's the only one that is widely enough understood to not put an additional learning burden on the user. When I learned Maven I had to grok concepts like dependencyManagement and plugins and phases. I didn't have to learn XML, I already knew it. If Maven POMs were written in Python or A.N.Other language/markup I'd have to learn that too. There are many useful libraries that make it easier to produce GUI tools on top of XML that don't exist for alternatives, so we'd have less tooling for POMs. Tooling and minimising the learning required are good things. The _actual_ problem I see is the lack of best practise use for plugins off the beaten track. The documentation is usually fairly good at telling you how to make a plugin do something, it's less than brilliant at recommending best practises and unless it's one of the mainstream ones covered by the sonatype book it's hard to find. I've found the best thing to do in those cases is go look at large, open source projects and see how they do it. Ken's original problem in this thread (and the others he's been getting help with on the scala list) are _nothing_ to do with XML, that is just the target of frustration. They would have happened regardless of the language for POM specification. For us, Maven's killed about 12,000 lines of ant legacy built up over a few years, and also done a drive by on a couple of dozen ivy files, replacing them with one medium size POM declaring dependency versions, a dozen small ones declaring dependencies, and a bunch of minimal ones - all with NO bespoke build instructions in. Using nexus has killed the need to maintain an internal ivy repository which was a real pain in the rear, and we can now easily share deliverables with the other couple of hundred developers we have working in the same technologies around the globe. It's been very painless by comparison to what we were doing before and well worth the switchover. Regards Brian On 15 October 2010 08:56, mremerson...@aim.com wrote: On Fri, Oct 15, 2010 3:00 am, Jason van Zyl wrote: A fact to note though is that I've asked over 2k people over the last two years at talks and in any average crowd the people who care to have a different format or DSL is around 3%. And I one of them :-) I always havent been a friend of XML and I happy to see the possibilities maven3 offers (although I prefer using gradle - bygones) What I'm wondering most is - why the heck do you write to the maven mailinglist how you dislike maven ? Is your intention to convince people that they are doing bad stuff over the last xxx years ? Is it just pure boredness ? I dont like Ruby or Clojure - what is the reason to bother the ruby/clojure mailing list that their syntax is apparently horrible ? Sorry - I dont get it... If you dont like maven - dont use it... there are tons of alternatives around. Or what point do I miss here ?
Re: maven is a swamp
On 15 October 2010 21:50, Kenneth McDonald kenneth.m.mcdon...@sbcglobal.net wrote: Well, just to make it concrete, I am not a troll. I've been doing dev for 20+ years, have lots of experience with large projects, etc. etc. If I have to drop names, I was associated with one of the two main sites of the Human Genome Project. I still don't get the complacency at the XML swamp. How is genericTagNamefalse/genericTagName possibly better than genericTagNamefalse/ which would in turn be better than: genericTagName = false XML is a swamp of undertulized, overused redundancy. Period. In response to the person who'd interrogated 2K+ people to see if they thought XML was overrdone; Wow, that's really impressive! Where did you find the time to ask all those people and still get your your job done? Whereas, if I ask the five people who I know well, and who have to use these tools, the answer is, what a bunch of garbage. They HATE XML. Still not convinced? What about the simple fact of that that languages before, and the languages _since_ have not been written in a dialect of XML. If XML were such a great solution, surely it would have cleared here by now. But of course it hasn't. The reasons is because it's a CRAPPY SOLUTION. Period. No Line breaks. Unless one is writing for ultimate display in the web, XML SUCKS In all the best to have all the people who have responded to this, I don't see how you can continue maintain your position, Yours, Ken I don't think you're going to convince many people with a rant like that. Not one person in this thread has taken the position that XML is great. I don't think anybody, even the people who did design it, would design XML the same way now. There are far stronger criticisms of it than named end tags though. It is like it is for a bunch of reasons that are to do with its hereditary burden carried from SGML, the people involved in the original specification and (sadly) the process of managing that amongst other reasons. If you're interested the history and design decisions can be read up at the w3c. However even acknowledging that there are valid and well thought out criticisms of XML design beyond the ones you've brought up in this thread, it hasn't become so widely used (and misused) by some accident. It is very popular for exactly the reason that it was the best choice for maven - because it is very simple to understand and to build tools for. I think really you're lucky POMs are in XML, because if they were in something like python you'd have had all of the same difficulties without the target to vent at. And with far less help, since maven would not be nearly as popular if read a POM required people to learn a programming language as well as the semantics for maven. I hope you get over the XML thing and find maven useful to you - best way to do that is to follow conventions and use tools. Regards Brian
Re: multi-module project versioning question
What I find helped me tremendously when figuring out the best way to organise our project is to look at examples. Large scale open source projects like the spring framework and maven itself are good places to learn. regards Brian On 30 September 2010 13:32, Antonio Petrelli antonio.petre...@gmail.comwrote: 2010/9/30 Nathaniel Auvil nathaniel.au...@gmail.com: what does not make sense to you? If i only have a bug in the child-web project, i should not have to release a new version of my child-service and child-core...those did not change. I understand the point, but its intrinsically wrong. When you fix something inside a module you are, in fact, fixing the whole project. Otherwise, if you want to manage those module separately, you'd better move them in a separate project. In fact, one main point of a multi-module project is to maintain the versions of modules all together. This is fundemental to multi-module projects and i do not see how maven can not support this. Releasing all modules of a project at the same time does not make sense in this case. You can try going in the module subdir and running the release plugin. It *might* work, however I strongly discourage it. Right now i have separate projects for each module, but it is painful to do builds and releases. Doing as I said in the sentence before is painful in the exact same way. It would be less painful if you tag only the main project. Another issue with multi-module projects is how they have to live in SVN...if you want to tag or branch, you have to tag or branch the entire codebase, not just a single module. At this point I suppose you are managing projects in a wrong way. Why did you put the whole codebase under a single project? If it is only for sharing configuration, then create a separate master pom and use it as parent for all the other projects. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [scala-user] Solution to scalatest test phase under maven
Ken Glad to hear you have it fixed. It makes sense now, our project had to use manifest jars because we had so many third party libraries required for unit testing that the classpath got too long for the windows command line. They basically contain (for us) a manifest pointing to the other jars for the sole purpose of shortening that command line. I guess the surefire plugin had the same problem and there is something about how they are specified in the manifest which doesn't work on your filesystem, http://maven.apache.org/plugins/maven-surefire-plugin/examples/class-loading.html Thanks for posting the solution Brian On 28 September 2010 18:47, Kenneth McDonald kenneth.m.mcdon...@sbcglobal.net wrote: Posting this in hopes it will help others. First, I'd like to heartily thank everyone who gave of their time with helping me in this problem. I learned a log about maven (more than I really want to :-) but it's good for future jobs), and I wouldn't have found the solution on my own without a _lot_ more time. Basically, a couple of people sent me pom files which worked for them, but which didn't work for me. I don't know why, this is still a mystery. What did work was the following highlighted line: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.6/version configuration useManifestOnlyJarfalse/useManifestOnlyJar includes include**/*Test.*/include include**/*Suite.*/include /includes /configuration /plugin I'm going to have to dig into the Maven documentation and refresh my memory of manifests (its been _years_ since I've used Java) to figure out exactly what is going on, but once I added this, my tests ran smoothly. (And I am happy to say, all are still OK :-) ). Again, many thanks to all, Ken McDonald
Re: What is your strategy to manage dependencies?
Yes - it's a multi module project. It has several levels in fact and delivers two web apps and three izpack installed core java/swing apps. We do sometimes release modules internally with no change but a new version number. It doesn't actually cause us any problems and the consistency is worth the extra bandwidth. Our external release cycle is much longer so our real end users always get a set of applications that have a significant set of changes in them with accompanying release notes generated from svn log + jira. The huge benefit for us was the reduction in time to administrate third party library versions. Cheers Brian On 29 September 2010 23:59, Mario Wirth mario.wi...@gmx.net wrote: Hi Brian, is your project configuration a multi module project? If so, I guess this is a nice solution. If you release all your modules at the same time, you will never have dependency conflicts. Disadvantage of that approach is, that you sometimes release moduls without a change. Am I right? Mario Am 29.09.2010 00:42, schrieb Brian Smith: Hi Mario Unless I'm misunderstanding - I do 2) for dependencies of external libraries plus 4) for dependencies on my own modules. I only specify versions of external dependencies in dependencyManagement in the parent, and do so with properties so they're convenient to change. Child poms just inherit versions from the parent dependencyManagement. I keep the versions of my own modules as SNAPSHOT of the next version, until release time and then release them all with the same version. Then set the versions to SNAPSHOT for the next (likely) version. This way I only maintain dependency versions in one place and everything that is released is consistent. I haven't needed version ranges or found diffcult conflicts despite depending on dozens of your fairly common java libraries. Hope that helps Brian On 28 September 2010 22:29, Mario Wirthmario.wi...@gmx.net wrote: Thank you Antonio, for your response. But is this really the only solution? Is there no plugin or technique available which helps to avoid (binary) compatibility conflicts between artifacts? Can anyone recommend the use of version ranges? Thanks, Mario Am 24.09.2010 09:47, schrieb Antonio Petrelli: 5. Use released versions if possible and resolve conflicts one by one. Antonio 2010/9/24 Mario Wirthmario.wi...@gmx.net: Hi community, I am interested in your strategy, how to use Maven to make sure, all artifacts are selected in the right version. By default, if you add a dependency with it's version, that is only a wish. Maven is allowed to change the artifact to a newer or an older version. It depends on the dependency tree and the distance to the root. (see: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges ) As a consequence, sometimes my war file contains libs which do not fit together. The following solutions I've figured out so far: 1.Declare all needed dependencies in the pom of the war file. Disadvantage: I have to do the work manually. 2.Use Dependency Management. In my parent pom I can declare all dependencies and their versions. Advantage: I have full control of the dependencies in the child moduls. Disadvantage: If I need to change a version of a particular dependency, I need to release a new version of the parent pom and afterwards I have to update the version number in all child projects which need the new version of the dependency. 3.Use Version Ranges. Advantage: With version ranges I can add more specific informations for Maven. This is used to support the conflict resolution and maven only selects artifacts which satisfy all version ranges. Advantage: conflict resolution does not cause (binary) incompatibilty between the artifacts, if the version ranges are set correct. Disadvantage: There is more effort during the release process: you need to build a release pom with resolved version ranges to make the build repeatable. You have to hide Snapshots during the release process, if you use boundaries like [4.0,). And finally, maven needs additional meta data from the repository. If the meta data are not up to date, strange behaviour can happen. 4.Use only snapshots. If I use only snapshot versions, the latest version is always used. Disadvantage: Developing against snapshots can be frustrating because of the nature of snapshots ;-) But you will find out very fast, if something is binary incompatible. So, I am very interested in the best practise! How do you solve the problem to manage all dependencies in their correct version. Thank you for your suggestions in advance. Mario - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What is your strategy to manage dependencies?
In this situation I would simply not allow A to depend on C-1.0.0. I'd upgrade to C-2.0.0 for all modules and deal with whatever change A had to swallow to sustain that. Less surprises, problems found earlier. I haven't encountered a situation where it would be beneficial to do otherwise yet. Using dependencyManagement in a parent pom is just following DRY. I'm not saying version ranges can't be a useful way of working, I'd just prefer to be sure of what was being delivered. We do have a huge battery of automated acceptance tests running under CI so we can afford to upgrade drop in replacements often with low risk. Cheers Brian On 30 September 2010 00:07, Mario Wirth mario.wi...@gmx.net wrote: Sorry, for the misleading post. I declare all dependencies, which are needed for compile in the project's pom (not parent pom). I trust on maven's conflict resolution and don't use Dependency Management at all at the moment. The reason for that I have described already: I don't want to release the parent pom and update the new version number in each child. If I don't do that, former builds are not repeatable. But if you trust maven's conflict resolution, it can lead to the following situation: There are 3 projects and their releationship: A-1.0.0 → B-1.0.0 → C-2.0.0 In addition A as the following dependency: A-1.0.0 → C-1.0.0 If project A is a war, it's lib folder will include B-1.0.0 and C-1.0.0. But B-1.0.0 needs classes which are only available in C-2.0.0. Consequence: You will get an exception at runtime. With version ranges you can avoid that. You have to write in the POM of B → C[2.0.0, 2.1). Maven will consider this additional information and select version C-2.0.0. But version ranges lead to other problems. You need correct meta-data and you have to create a release pom to resolve the version ranges at release time. (see: http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html ) I really would like to use version ranges, but I read very often in this forum: Avoid version ranges! (the post of Michael McCallum is an exception ;-) ) I am not sure if it's the maven way. On the other hand: If you do the dependency management manually, you use Maven just to download the artifacts. Is that the maven way? Thanks, Mario Am 29.09.2010 15:27, schrieb Yanko, Curtis: I do find it surprising that your saying declaring a dependency is *only a wish*? A declared dependency *should be* closest to the root, our do you make your declarations in a Parent POM? We too used to *factor up* any shared dep to the Parent but have stopped since it creates a couple of issues, yours being just one of them. 2.Use Dependency Management. In my parent pom I can declare all dependencies and their versions. Advantage: I have full control of the dependencies in the child moduls. Disadvantage: If I need to change a version of a particular dependency, I need to release a new version of the parent pom and afterwards I have to update the version number in all child projects which need the new version of the dependency. If you are declaring versions in depMgmnt, don't put a version in the project pom dependency. Work with a SNAPSHOT POM version until you have what you want, then RELEASE it, to nail it down. I don't advocate version ranges at all since your build may not be re-produceable if you do. Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Michael McCallum [mailto:mich...@redengine.co.nz] Sent: Tuesday, September 28, 2010 5:51 PM To: Maven Users List Subject: Re: What is your strategy to manage dependencies? I highly recommend using version ranges, in fact i wonder how people work without them, it must be really hard to keep track of all the dependencies. On Wednesday 29 September 2010 10:29:36 Mario Wirth wrote: Thank you Antonio, for your response. But is this really the only solution? Is there no plugin or technique available which helps to avoid (binary) compatibility conflicts between artifacts? Can anyone recommend the use of version ranges? Thanks, Mario Am 24.09.2010 09:47, schrieb Antonio Petrelli: 5. Use released versions if possible and resolve conflicts one by one. Antonio 2010/9/24 Mario Wirthmario.wi...@gmx.net: Hi community, I am interested in your strategy, how to use Maven to make sure, all artifacts are selected in the right version. By default, if you add a dependency with it's version, that is only a wish. Maven is allowed to change the artifact to a newer or an older version. It depends on the dependency tree and the distance to the root. (see: http://www.sonatype.com/books/mvnref-book/reference/pom-relationshi ps-sect-project-dependencies.html#pom-relationships-sect-version-ra nges) As a consequence, sometimes my war file contains libs which do not
Re: What is your strategy to manage dependencies?
Hi Mario Unless I'm misunderstanding - I do 2) for dependencies of external libraries plus 4) for dependencies on my own modules. I only specify versions of external dependencies in dependencyManagement in the parent, and do so with properties so they're convenient to change. Child poms just inherit versions from the parent dependencyManagement. I keep the versions of my own modules as SNAPSHOT of the next version, until release time and then release them all with the same version. Then set the versions to SNAPSHOT for the next (likely) version. This way I only maintain dependency versions in one place and everything that is released is consistent. I haven't needed version ranges or found diffcult conflicts despite depending on dozens of your fairly common java libraries. Hope that helps Brian On 28 September 2010 22:29, Mario Wirth mario.wi...@gmx.net wrote: Thank you Antonio, for your response. But is this really the only solution? Is there no plugin or technique available which helps to avoid (binary) compatibility conflicts between artifacts? Can anyone recommend the use of version ranges? Thanks, Mario Am 24.09.2010 09:47, schrieb Antonio Petrelli: 5. Use released versions if possible and resolve conflicts one by one. Antonio 2010/9/24 Mario Wirthmario.wi...@gmx.net: Hi community, I am interested in your strategy, how to use Maven to make sure, all artifacts are selected in the right version. By default, if you add a dependency with it's version, that is only a wish. Maven is allowed to change the artifact to a newer or an older version. It depends on the dependency tree and the distance to the root. (see: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges ) As a consequence, sometimes my war file contains libs which do not fit together. The following solutions I've figured out so far: 1.Declare all needed dependencies in the pom of the war file. Disadvantage: I have to do the work manually. 2.Use Dependency Management. In my parent pom I can declare all dependencies and their versions. Advantage: I have full control of the dependencies in the child moduls. Disadvantage: If I need to change a version of a particular dependency, I need to release a new version of the parent pom and afterwards I have to update the version number in all child projects which need the new version of the dependency. 3.Use Version Ranges. Advantage: With version ranges I can add more specific informations for Maven. This is used to support the conflict resolution and maven only selects artifacts which satisfy all version ranges. Advantage: conflict resolution does not cause (binary) incompatibilty between the artifacts, if the version ranges are set correct. Disadvantage: There is more effort during the release process: you need to build a release pom with resolved version ranges to make the build repeatable. You have to hide Snapshots during the release process, if you use boundaries like [4.0,). And finally, maven needs additional meta data from the repository. If the meta data are not up to date, strange behaviour can happen. 4.Use only snapshots. If I use only snapshot versions, the latest version is always used. Disadvantage: Developing against snapshots can be frustrating because of the nature of snapshots ;-) But you will find out very fast, if something is binary incompatible. So, I am very interested in the best practise! How do you solve the problem to manage all dependencies in their correct version. Thank you for your suggestions in advance. Mario - 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: Maven FAQ
mvn dependency:go-offline seems like it does what you're after? Regards Brian On 29 September 2010 00:32, Greg Akins angryg...@gmail.com wrote: I'm trying to use some spare time to update the Maven FAQ Wiki In that document, an unanswered question is: How about making sure all files needed are available so I can run disconnected? My first impression is to run the goals successfully before running disconnected (mvn -o goal). However, it occurs to me that there might be a way to use the dependency goal, or something else to make sure that all dependencies are available, even those for targets that aren't commonly run. I'm thinking of something along the line of download all dependencies instead of just those associated with a single goal. Does that make sense? Or is my first impression correct? -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
xdoclet maven plugin: Ambiguous subtask definition exception
I'm getting an error (Ambiguous subtask definition exception) while trying to run Maven from the top directory of a multi-module project that contains both EJBs and web apps. I've seen that this has been reported before and that a bug was created and has been closed ( http://jira.codehaus.org/browse/MOJO-223). Supposedly this is an xdoclet issue. Has anyone ran into this lately and found a way to work around this? The solution on the bug report won't work because it says the plugin doesn't exist. Also, are other developers not relying on a tool (xdoclet or ejbgen or ??) to create descriptors? Thanks, Brian
Re: xdoclet maven plugin: Ambiguous subtask definition exception
I'll give that a try. I finally figured out my issue with the getting the correct version of the plugin but I'm still getting the same error. On 9/6/07, Marco Mistroni [EMAIL PROTECTED] wrote: Hello, i had.. long time ago while i was trying to do exactly the same thing. Resorted to use xdoclet in one project, and to call xdocket from maven antrun plugin in the other not elegant, but was theonly solution i found hth marco On 9/6/07, Brian Smith [EMAIL PROTECTED] wrote: I'm getting an error (Ambiguous subtask definition exception) while trying to run Maven from the top directory of a multi-module project that contains both EJBs and web apps. I've seen that this has been reported before and that a bug was created and has been closed ( http://jira.codehaus.org/browse/MOJO-223). Supposedly this is an xdoclet issue. Has anyone ran into this lately and found a way to work around this? The solution on the bug report won't work because it says the plugin doesn't exist. Also, are other developers not relying on a tool (xdoclet or ejbgen or ??) to create descriptors? Thanks, Brian
Eclipse setup for Multi-module project
Has anyone come up with a decent way to setup a project in Eclipse that will support a multi-module project? The best example I've seen is in the Better Builds with Maven book ( http://www.devzuz.com/web/guest/products/resources#BBWM - Chapter 4) but I'm having some difficulty. The book is creating the DayTrader application and recommends the file structure that I've tried to describe below. It also mentioned that this flat structure is the best and a nested directory structure has some drawbacks -- especially for Eclipse users. daytrader | +--ear | +... | +--ejb | +... | +--streamer | +... | +--web | +... | +--wsappclient | +... | +--pom.xml Unless I'm missing something, this is a nested directory structure. I've tried creating Java Projects and Simple Projects in Eclipse for the daytrader. I've tried source folders for the ear, ejb... I can't seem to get this directory structure to work using Eclipse. Has anyone found a good way to make this work? I'm a maven newbie but it seems that there is some incompatibility between one of the main IDEs (Eclipse) and Maven. If Maven is geared to a particular directory structure and Eclipse to another, and you have to have major tweaks to Maven to make everything work, then you lose a large percentage of the benefits of using Maven. Hopefully I'm missing something easy on how to setup a project in Eclipse.
Re: xdoclet plugin and weblogic-ejb-jar.xml descriptor
I'm using Weblogic 9.2. I think you're correct in that the weblogic plugin only works for versions 8.x and earlier. I haven't found any great solutions for this hurdle yet. On 8/31/07, Scott Ryan [EMAIL PROTECTED] wrote: What version of Weblogic are you using? You can use the weblogic tag to generate the XML files but as far as I know xdoclet can only generate xml files for 8.x and prior. 9.x and 10.x are not supported but then maybe you should be using JPA, EJB 3.0 or Hibernate by then. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] On Aug 31, 2007, at 9:34 AM, Brian Smith wrote: I'm working on a simple HelloWorldEJB stateless session bean that I want to run in Weblogic. I'm using the xdoclet plugin and xdoclet is able to generate the home/remote classes. Should xdoclet be able to generate the weblogic-ejb-jar.xml descriptor? If so, how do I do this? Is there a special tag in the EJB source code or is there something in the pom I need to specify? I'm guessing this a task of xdoclet instead of maven but I'm not sure. Any input would be appreciated. Thanks, Brian
Re: Eclipse setup for Multi-module project
Nick, I'm trying to keep things really small at this point (like HelloWorlds) but I setup a directory structure similar to the DayTrader and performed the import into eclipse. First thing I noticed (and I think this is what you mentioned) is that the top level directory is not there. Because of this, I can't run Maven (mvn install) because the parent pom is not available. You mentioned making a symlink but we're developing on our PCs (XP). Directory Structure Eclipse === === TestApp + testcommon + testcommon + testejb + testejb + testear + testear So, it seems like I'm back to where I started. Eclipse and Maven aren't too compatible. All the books and articles talk about a flat directory structure but it's really nested. Maven needs (or recommends) a top directory to hold the parent pom but Eclipse doesn't like the notion of sub-projects. I'm using CVS and I've played with the idea of having something setup like the following where I have a parent directory that just holds the parent pom and the ear to create the ear and then the two modules that actually hold the code but this seems pretty ugly. At least with Ant I can layout the code the way I want too. Eclipse === + testcommon + testejb + testear + testparent On 9/4/07, Nick Stolwijk [EMAIL PROTECTED] wrote: In your daytrader directory, run mvn eclipse:eclipse. This will create the .project and .classpath files of the child modules with dependencies for eclipse between them if necessary. Then, in Eclipse, import your projects. If you want your parent pom.file easily accessible from eclipse, make a symlink to it from one of the other directories. If your developers use a SCM from Eclipse (like subclipse) they will not pickup any changes to the root directory. That's why we've setup our environment to send mails when the root pom changes. (This was often a pain in the butt, people not upgrading their parent pom) I hope it is clear, if not, ask. Nick Stolwijk Brian Smith wrote: Has anyone come up with a decent way to setup a project in Eclipse that will support a multi-module project? The best example I've seen is in the Better Builds with Maven book ( http://www.devzuz.com/web/guest/products/resources#BBWM - Chapter 4) but I'm having some difficulty. The book is creating the DayTrader application and recommends the file structure that I've tried to describe below. It also mentioned that this flat structure is the best and a nested directory structure has some drawbacks -- especially for Eclipse users. daytrader | +--ear | +... | +--ejb | +... | +--streamer | +... | +--web | +... | +--wsappclient | +... | +--pom.xml Unless I'm missing something, this is a nested directory structure. I've tried creating Java Projects and Simple Projects in Eclipse for the daytrader. I've tried source folders for the ear, ejb... I can't seem to get this directory structure to work using Eclipse. Has anyone found a good way to make this work? I'm a maven newbie but it seems that there is some incompatibility between one of the main IDEs (Eclipse) and Maven. If Maven is geared to a particular directory structure and Eclipse to another, and you have to have major tweaks to Maven to make everything work, then you lose a large percentage of the benefits of using Maven. Hopefully I'm missing something easy on how to setup a project in Eclipse. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse setup for Multi-module project
Actually, I did select the Copy projects into Workspace checkbox so that may be the source of my problem. I've been experimenting a little bit and it seems that if I create the whole directory structure in C:\temp (c:\temp\TestApp) and then do the imports, everything seems to work as expected. If I go ahead and check in one of the submodules (say testcommon), and then delete the directory from disk and check out of the repository, the code is in my workspace as opposed to c:\temp\TestApp. In a team environment, this still seems pretty ugly. It appears that you have to jump through quite a few hoops to get this to work. Could you explain more about how you can import the top level project into eclipse? I was able to see the top level pom but it also had the sub modules as well. On 9/4/07, Francois Fernandes [EMAIL PROTECTED] wrote: One little Note about the importing of the projects: Ensure that Copy projects into workspace is deselected. Event the top level project can be imported into eclipse. To do this you generate the project files of the submodules and import them. Then create a new Project (not Java, a General Project) with exactly the name of your Top-Level Module (In your application: TestApp). Eclipse will not overwrite the directory. Instead it will discover the contents. Inside this project executing mvn install will be possible. Graham Leggett schrieb: On Tue, September 4, 2007 7:12 pm, Brian Smith wrote: First thing I noticed (and I think this is what you mentioned) is that the top level directory is not there. Because of this, I can't run Maven (mvn install) because the parent pom is not available. Why is the top level directory not there? One thing to make sure you do - check out the whole project using your source control tool of choice, then run mvn eclipse:eclipse from the root of your project, then import your projects into eclipse by selecting the root of your project and importing all the projects eclipse finds. Directory Structure Eclipse === === TestApp + testcommon + testcommon + testejb + testejb + testear + testear This is exactly what we have, and mvn install runs fine. Can you explain in more detail the exact steps you are trying to perform? Regards, Graham -- - 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: Eclipse setup for Multi-module project
I may be running into a couple of different issues. When I did my import, I selected the Copy projects into workspace which appears to ignore the top level directory. Also, I was trying to use Eclipse to check in/out of CVS. It appears that you don't use Eclipse to check the code into your workspace. If I'm understanding you correctly, you checkout to a temp directory and then import into Eclipse to do your work. Doesn't this cause problems in a team environment? Everyone would have to agree on the directory structure where the code will be checked out to? On 9/4/07, Graham Leggett [EMAIL PROTECTED] wrote: On Tue, September 4, 2007 7:12 pm, Brian Smith wrote: First thing I noticed (and I think this is what you mentioned) is that the top level directory is not there. Because of this, I can't run Maven (mvn install) because the parent pom is not available. Why is the top level directory not there? One thing to make sure you do - check out the whole project using your source control tool of choice, then run mvn eclipse:eclipse from the root of your project, then import your projects into eclipse by selecting the root of your project and importing all the projects eclipse finds. Directory Structure Eclipse === === TestApp + testcommon + testcommon + testejb + testejb + testear + testear This is exactly what we have, and mvn install runs fine. Can you explain in more detail the exact steps you are trying to perform? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xdoclet plugin and weblogic-ejb-jar.xml descriptor
I'm working on a simple HelloWorldEJB stateless session bean that I want to run in Weblogic. I'm using the xdoclet plugin and xdoclet is able to generate the home/remote classes. Should xdoclet be able to generate the weblogic-ejb-jar.xml descriptor? If so, how do I do this? Is there a special tag in the EJB source code or is there something in the pom I need to specify? I'm guessing this a task of xdoclet instead of maven but I'm not sure. Any input would be appreciated. Thanks, Brian
