RE: [m1.1] ant-optional classes not found
It's only an ant warning (new in 1.6.X). Don't care about it if you don't have a problem. Anraud -Message d'origine- De : Lukas Theussl [mailto:[EMAIL PROTECTED] Envoyé : vendredi 12 août 2005 23:07 À : Maven Users List Objet : [m1.1] ant-optional classes not found I just noticed that in 1.1-beta-1 running 'maven -X' with any goal produces a bunch of debug warnings: [DEBUG] Adding reference: maven.dependency.classpath Caching Taglib Uri -- deploy running script null [DEBUG] Could not load class (org.apache.tools.ant.taskdefs.optional.PropertyFile) for type propertyfile [DEBUG] Could not load class (org.apache.tools.ant.taskdefs.optional.clearcase.CCMkdir) for type ccmkdir ... and a few 100 more of that kind. The goals all execute fine, so there is no problem, I just noticed it using the -X option. The missing classes used to be in the ant-optional-1.5.3.jar, but this does not exist anymore in the ant version 1.6.5 used by m1.1b1. Does somebody know what that means and what to do about it? Thanks, Lukas - 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: [M1] Merge some web.xml deployment discriptor
Hi, Vincent Thank you for your information. But I had selected method with xsl. I will try cactus in the future. Thanks, Keisuke Vincent Massol wrote: Hi, There is a Cactus Ant task that can possibly help you: http://jakarta.apache.org/cactus/integration/ant/task_webxmlmerge.html -Vincent -Original Message- From: Keisuke Matsubara [mailto:[EMAIL PROTECTED] Sent: vendredi 12 août 2005 11:44 To: users@maven.apache.org Subject: [M1] Merge some web.xml deployment discriptor Hi, Is there plugin that merge some web.xml to one web.xml? I had reached following web site. http://java2.5341.com/msg/57779.html This page show me the method with xdoclet for merging ejb-jar.xml . I think it is good. Do you think I should newly create it for merging web.xml ? Thanks, Keisuke - 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]
Re: Plugin support for Hibernate 3.0
Where can I find the source code for Maven2's hibernate plugin? - Nadeem On Fri, 2005-08-05 at 18:57 +1000, Brett Porter wrote: The Maven2 hibernate support should be equivalent of the m1 hibernate support (just not an official release yet - but we're happy to have testers). And no more +1's needed. We get the picture ;) - Brett On 8/5/05, Jose Gonzalez Gomez [EMAIL PROTECTED] wrote: +1 more for Hibernate in M2... I'm testing M2 and was even thinking of going back to M1 to have the hibernate support back. Best regards Jose 2005/8/5, Brill Pappin [EMAIL PROTECTED]: +1 Hibernate for M2 lost without it :) - Brill Pappin Ken Weiner wrote: +1 for continued development of the hibernate plugin in M2. On 8/4/05, Brett Porter [EMAIL PROTECTED] wrote: That said, it has been brought across to to Maven2 and so we could continue development if there is demand and ad hibernate 3.0 features. Is anyone interested? - Brett - 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] - 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]
Assembly plugin -- couple of questions [m2a3]
All, I am trying to build an assembly for a multiproject setup in m2a3. I would like to verify what I am doing is ok (even if it may not be correct). What I would like to do is to build one tar/zip containing the jars (and dependencies) of all subprojects. I have defined an assembly descriptor only in the parent project. This descriptor defines a fileset for each subproject. Each fileset identifies the files I want to pick up from that particular subproject. This works fine. But since this is a multiproject build, after building the parent project, m2 tries to run the assembly goal the subprojects(modules) and fails (right now this is not an issue for me). I guess the way the assembly pluginis meant to work is to have individual descriptors for the subprojects(I suppose they could be empty descriptors in my case). is this understanding correct? I haven't got the dependencies to be included as yet. My question is - are the dependencies that the assembly plugin expects to be defined in the dependencyset element specific to that project or can I define the dependencies at the parent project level itself, even if they are really dependencies for the sub projects. Thanks Sid Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL format [a3 and m2a3]
On Fri, Aug 12, 2005 at 10:53:40PM -0700, Sidart Kurias wrote: Reading the posts I still cannot seem to get my url format correct...Keep getting the message you must provide a valid url. My url is scm:cvs:pserver:[EMAIL PROTECTED]:/cvsroot:projectname/pom.xml I have tried both with the pom.xml and dropping the pom.xml at the end. I can only assume this is now a password issue. Is the message the same if cvs access is denied. Where are you giving this url? What Continuum expects here is an URL to the pom.xml, like this: https://svn.apache.org/repos/asf/maven/components/trunk/pom.xml -- Trygve signature.asc Description: Digital signature
Re: Plugin support for Hibernate 3.0
On Sat, Aug 13, 2005 at 02:43:31AM -0700, Nadeem Bitar wrote: Where can I find the source code for Maven2's hibernate plugin? http://svn.mojo.codehaus.org/trunk/mojo/maven-hibernate-plugin/ -- Trygve signature.asc Description: Digital signature
Re: [m2] site documentation typo (with large consequences)
On Fri, Aug 12, 2005 at 12:08:43PM -0600, Julian Wood wrote: On this page: http://maven.apache.org/maven2/site.html where it says to configure reports, the groupId is groupIdorg.apache.maven.reports/groupId but I think it should be groupIdorg.apache.maven.plugins/groupId Seems right, please file a JIRA issue. -- Trygve signature.asc Description: Digital signature
Re: Maven2: Managing entire build process
Note that my answers are what Maven 2 can do. On Fri, Aug 12, 2005 at 05:23:25PM -0400, Rizwan Merchant wrote: I am working on implementing a build process for our project. This process is required to be run as a cron job. The build process is going to do a number of things, such as: 1. Back up build directory This step shouldn't be required, I would suggest that you always start with a clean directory. 2. Check out source code Maven should be able to do this, yeah. 3. set up build environment What steps do you want to perform here? 4. build the project 5. clean the database 6. build database I assume you mean a database that's used as a part of tests? If so, do the re-initialization in setUp() in your test cases. This will also make your tests independent of Maven (or whatever you build with) enabling you to run the tests from an IDE. 7. Perform regression tests If you implement this through a set of JUnit tests Maven can perform them for you. 8. Failure notification (emails to various groups/individuals) etc etc My questions are: Does maven2 provide functionality to manage and run this entire build process? I am not sure if I am clear or not, but would I need to write a batch file that will individually call each of the above tasks, or can I use maven2 to achieve this functionalitiy. Also, can all of the individual tasks mentioned above be performed using maven2? or do i need to achieve some of them using other means, such as ant ? (for example, i know I can achieve 2 and 4 using maven2..what about the others?) Maven 2 + Continuum[1] can together do this. Maven 2 will do the build parts and Continuum will do the cleaning, checking out and notifaction bits. [1]: http://maven.apache.org/continuum/ -- Trygve signature.asc Description: Digital signature
[1.1Beta] BUILD FAILED on jelly plugin. Please help.
All, How and where am I supposed to set the 'defaultValue' as indicated below? Thanks, Erwin xdoc:jelly-transform: About to use JSL stylesheet file:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl [echo] en [echo] The current Locale is the default one [echo] Scanning 'D:\...\target\generated-xdocs'... [echo] Generating D:/.../target/docs/checkstyle-report.html from D:\...\target\generated-xdocs\checkstyle-report.xml BUILD FAILED File.. D:\...\.maven\cache\maven-xdoc-plugin-1.9.1\plugin.jelly Element... j:include Line.. 479 Column 58 file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:33:17: jsl:stylesheet file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:146:57: jsl:applyTemplates file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:230:105: maven:property You must define an attribute called 'defaultValue' for this tag. Total time : 55 seconds Finished at : Saturday, August 13, 2005 9:46:36 AM EDT - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [1.1Beta] BUILD FAILED on jelly plugin. Please help.
You need to set the currentVersion/ in the project section of the project.xml file. -Original Message- From: Hogeweg, Erwin (GE Infrastructure) Sent: Saturday, August 13, 2005 10:01 AM To: Maven Users List Subject: [1.1Beta] BUILD FAILED on jelly plugin. Please help. All, How and where am I supposed to set the 'defaultValue' as indicated below? Thanks, Erwin xdoc:jelly-transform: About to use JSL stylesheet file:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resource s/site.jsl [echo] en [echo] The current Locale is the default one [echo] Scanning 'D:\...\target\generated-xdocs'... [echo] Generating D:/.../target/docs/checkstyle-report.html from D:\...\target\generated-xdocs\checkstyle-report.xml BUILD FAILED File.. D:\...\.maven\cache\maven-xdoc-plugin-1.9.1\plugin.jelly Element... j:include Line.. 479 Column 58 file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:33:17: jsl:stylesheet file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:146:57: jsl:applyTemplates file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resources/site.jsl:230:105: maven:property You must define an attribute called 'defaultValue' for this tag. Total time : 55 seconds Finished at : Saturday, August 13, 2005 9:46:36 AM EDT - 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: [m2] Mojo development: need ClassWorld
Trygve Laugstøl wrote: The reason as to why you can't get access to the classloader of the core is that the Mojos are supposed to be independent of their enviroment and they should be executed independently in separate class loaders. Giving the Mojos access to the root class loader will conflict with these ideas. Trygve, In the Springframework documentation they talk about 2 different types of beans, those that are not container aware and those that are. They always make cautionary statements when talking about container aware beans, but they didn't write Spring with an apriori knowledge of all future Spring use cases, so they made allowances for this odd behavior. It seems to me that attempting to define and enforce conventions like these simply reduces the chance that developers will want to adopt Maven. I see in the Maven User's list that the Maven developers are continually requesting use cases from the developers who use the framework in ways not intended or at least unexpected by the developers. Well, a successful tool/framework takes its users likely use cases into account up front, and or expands its list of use cases as they are presented. I'm not trying to say that you guys don't do that, but I will suggest that you tend to express reluctance. You guys aren't referred to as Mavenites by the rest of the community for no reason. ;-) If you think about Ant's success for a minute, I think that you can see that it allows a developer to do almost anything, including shoot him/her self in both feet. By reducing the possible Maven throws up steep hills for newbies, like I once was, to climb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Mojo development: need ClassWorld
On Sat, 13 Aug 2005, Andy Glick wrote: If you want to access the ClassRealm, just add a private field of type ClassRealm to the mojo, marking it as a @parameter. I needed this to construct a classpath string since the classloading of the app I embedded didn't implement classloading properly. I would rather not have the need for a classrealm too. -- Kenney Trygve Laugstøl wrote: The reason as to why you can't get access to the classloader of the core is that the Mojos are supposed to be independent of their enviroment and they should be executed independently in separate class loaders. Giving the Mojos access to the root class loader will conflict with these ideas. Trygve, In the Springframework documentation they talk about 2 different types of beans, those that are not container aware and those that are. They always make cautionary statements when talking about container aware beans, but they didn't write Spring with an apriori knowledge of all future Spring use cases, so they made allowances for this odd behavior. It seems to me that attempting to define and enforce conventions like these simply reduces the chance that developers will want to adopt Maven. I see in the Maven User's list that the Maven developers are continually requesting use cases from the developers who use the framework in ways not intended or at least unexpected by the developers. Well, a successful tool/framework takes its users likely use cases into account up front, and or expands its list of use cases as they are presented. I'm not trying to say that you guys don't do that, but I will suggest that you tend to express reluctance. You guys aren't referred to as Mavenites by the rest of the community for no reason. ;-) If you think about Ant's success for a minute, I think that you can see that it allows a developer to do almost anything, including shoot him/her self in both feet. By reducing the possible Maven throws up steep hills for newbies, like I once was, to climb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Mojo development: need ClassWorld
On Sat, Aug 13, 2005 at 10:33:51AM -0400, Andy Glick wrote: Trygve Laugstøl wrote: The reason as to why you can't get access to the classloader of the core is that the Mojos are supposed to be independent of their enviroment and they should be executed independently in separate class loaders. Giving the Mojos access to the root class loader will conflict with these ideas. Trygve, In the Springframework documentation they talk about 2 different types of beans, those that are not container aware and those that are. They always make cautionary statements when talking about container aware beans, but they didn't write Spring with an apriori knowledge of all future Spring use cases, so they made allowances for this odd behavior. There are always ways around this, one way is to write a Plexus component and have a @parameter on that in the Mojo. Any Plexus component can get access to the container which should solve the problem. That solution would still not break the Mojo API and if you're using the Mojo in another container the container would either have to provide the component or gently fail because of the missing requirement. It's worth noticing that the Mojo API is more of a bridge between existing code and the execution enviroment (be it Maven, any IDE or tool) so the API it pretty limited and specific. It seems to me that attempting to define and enforce conventions like these simply reduces the chance that developers will want to adopt Maven. I see in the Maven User's list that the Maven developers are continually requesting use cases from the developers who use the framework in ways not intended or at least unexpected by the developers. Well, a successful tool/framework takes its users likely use cases into account up front, and or expands its list of use cases as they are presented. I'm not trying to say that you guys don't do that, but I will suggest that you tend to express reluctance. Maven has always been about creating build patterns to make it easier to perform builds and maintaining builds. Maven should cover most use cases you have when it comes to building software but it might not be the way you expect and you might have to change your exising build. That is why that we sometimes are reluctant to You guys aren't referred to as Mavenites by the rest of the community for no reason. ;-) If you think about Ant's success for a minute, I think that you can see that it allows a developer to do almost anything, including shoot him/her self in both feet. By reducing the possible Maven throws up steep hills for newbies, like I once was, to climb. By making everything possible with Maven wouldn't that make Maven the same thing as Ant? If Maven doesn't do the job, Ant will. As for the steep hills, that seems to be mostly comments from Ant people, which is understandable given the two different ways stuff is done. The site is pretty good now and it should be pretty easy to get started with Maven. -- Trygve signature.asc Description: Digital signature
RE: [1.1Beta] BUILD FAILED on jelly plugin. Please help.
Can you fill an issue for the xdoc plugin please. The error message isn't really explicit :-) Arnaud -Message d'origine- De : Hogeweg, Erwin (GE Infrastructure) [mailto:[EMAIL PROTECTED] Envoyé : samedi 13 août 2005 16:10 À : Maven Users List Objet : RE: [1.1Beta] BUILD FAILED on jelly plugin. Please help. You need to set the currentVersion/ in the project section of the project.xml file. -Original Message- From: Hogeweg, Erwin (GE Infrastructure) Sent: Saturday, August 13, 2005 10:01 AM To: Maven Users List Subject: [1.1Beta] BUILD FAILED on jelly plugin. Please help. All, How and where am I supposed to set the 'defaultValue' as indicated below? Thanks, Erwin xdoc:jelly-transform: About to use JSL stylesheet file:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resource s/site.jsl [echo] en [echo] The current Locale is the default one [echo] Scanning 'D:\...\target\generated-xdocs'... [echo] Generating D:/.../target/docs/checkstyle-report.html from D:\...\target\generated-xdocs\checkstyle-report.xml BUILD FAILED File.. D:\...\.maven\cache\maven-xdoc-plugin-1.9.1\plugin.jelly Element... j:include Line.. 479 Column 58 file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resou rces/site.jsl:33:17: jsl:stylesheet file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resou rces/site.jsl:146:57: jsl:applyTemplates file:/D:/.../.maven/cache/maven-xdoc-plugin-1.9.1/plugin-resou rces/site.jsl:230:105: maven:property You must define an attribute called 'defaultValue' for this tag. Total time : 55 seconds Finished at : Saturday, August 13, 2005 9:46:36 AM EDT - 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]
Re: Multiproject site navigation question
Wendy Smoak wrote: From: Jay H. Hartley [EMAIL PROTECTED] You mention that you need to have the documentation as part of the root web site. Would having it one link down but clearly labeled at the top of the sub-project list satisfy the need? No, the files really need to be up at the top level. I'm integrating the existing Struts site into the Maven-generated multi-project site, and I don't want to break all the links that are already out there. It's looking good so far... I just wanted to be sure I wasn't doing more work than necessary in navigation.xml. :) Another multiproject site question: Is there a way to override the directory name that 'multiproject:site' comes up with for each subproject? It seems to be coming from the id tag in project.xml. Some of the ids don't match the directory names we've been using for those projects, but they are correct for use in the .jar file name. For example, the Struts Flow website is http://struts.apache.org/flow, yet its id is 'struts-flow'. Once the documentation gets pushed down under /struts/current/flow/xdocs, I need to retain the directory name for the website, yet the .jar file needs to be struts-flow-x.x.x.jar. There's a property for everything else. :) But I don't see anything relevant on http://maven.apache.org/reference/plugins/site/properties.html Is this possible to override, or is the answer possibly as simple as a postGoal to rename the directory? No, there is no way to override this. The multiproject plugin creates the directories in a loop over subprojects, using the artifact id to name each directory. Using a postGoal to multiproject:site to rename should work, assuming you are specifying your own nav's. Phil Thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
An oversight in the plugin matrix WRT the existing M1 plugin for commons-attributes
It turns out that there is a working maven plugin that is distributed with commons-attributes. It was used with out difficulty at a company where i did some work, and I have been able to get it to work. So the keeper of the matrix might want to move the entry for commons-attributes out of the new in Maven2 group. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] repositories entry is being ignored
I have a repositories entry that seems to be ignored, since it produces the following output: --- [EMAIL PROTECTED] eclipse-libraries]$ m2 --offline install [INFO] Maven is running in offline mode. [INFO] [INFO] Building Eclipse libraries [INFO]task-segment: [install] [INFO] [INFO] maven-install-plugin: resolved to version 2.0-beta-1-SNAPSHOT from local repository [INFO] maven-install-plugin: using locally installed snapshot [INFO] maven-plugin-parent: using locally installed snapshot [INFO] maven-assembly-plugin: using locally installed snapshot [WARNING] * Using defaults for missing POM org.eclipse:libraries:pom:3.1 * [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Main Error: Unable to download the artifact from any repository org.eclipse:libraries:3.1:zip from the specified remote repositories: http://repo1.maven.org/maven2 Path to dependency: 1) net.agentis:eclipse-libraries:pom:1.0-SNAPSHOT 2) org.eclipse:libraries:zip:3.1 Root error: Unable to download the artifact from any repository --- An extract from my pom is: repositories repository idcentral/id nameCentral Development Repository/name urlfile://localhost/home/jas/agentis/repo/central/url snapshotPolicyalways/snapshotPolicy /repository /repositories dependencies dependency groupIdorg.eclipse/groupId artifactIdlibraries/artifactId version3.1/version typezip/type /dependency /dependencies --- I think the integrity of my repository is OK - it has the format shown below. (I've also tried putting a repository directory above org). I've tried the libraries-3.1.pom file with both packaging of 'pom' and 'zip', but no joy. Maybe m2 doesn't support depending on zips? /home/jas/agentis/repo/central/ |-- org `-- eclipse |-- libraries `-- 3.1 |-- libraries-3.1.pom `-- libraries-3.1.zip
Dependency Management - Need advice
Hello all, I am going to have a m2 build system that contains lots of sub projects. my daily build uses the same version of all sub projects. and the version is incremented for each daily build. In M1, I use one global version property in project.properties of the master project root. For each daily build, the system increments the version in properties and tag the entire source tree. In m2, it seems that the only way to achieve this are: - Define all possible sub projects in dependencyMangement at the root pom or - I need to write a plugin to transerse to all subproject and change the version in poms and their dependencies,check in all the changes before the build Each has its own complexities that I wish to avoid I also notice that m2 and continuum builds also have to go thru my scecario for each new release ( offical alpha, beta,etc). Is there a better way? Or the capability is already there in M2. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1] ant-optional classes not found
dan tran wrote: in 1.1 you need to load the optional jars yourself http://maven.apache.org/reference/backwards-compatibility.html -D I was aware of that but that's the point: I am not using any optional tasks. It already happens if I just run the genapp plugin inside an empty directory. I also know that it's just a warning, everything seems to work fine, I wouldn't have noticed anything without the -X option. It's just discomforting to have this bunch of debug warnings - especially if you are trying to filter out a real problem. Lukas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: An oversight in the plugin matrix WRT the existing M1 plugin for commons-attributes
will do. Actually, I think commons-attributes provides this themselves... - Brett On 8/14/05, Andy Glick [EMAIL PROTECTED] wrote: It turns out that there is a working maven plugin that is distributed with commons-attributes. It was used with out difficulty at a company where i did some work, and I have been able to get it to work. So the keeper of the matrix might want to move the entry for commons-attributes out of the new in Maven2 group. - 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: Assembly plugin -- couple of questions [m2a3]
This is eomthing we want to make possible in beta-1. In Maven 1 (and what we have supported so far), aggregation was done through a separate project, pulling in the dependencies (eg, an EAR). However, we want to support top level aggregation that pulls in subprojects instead, as well. A workaround is to create a suproject that depends on all the modules you want to aggregate and includes them (their transitive deps will also be included). - Brett On 8/13/05, Sidart Kurias [EMAIL PROTECTED] wrote: All, I am trying to build an assembly for a multiproject setup in m2a3. I would like to verify what I am doing is ok (even if it may not be correct). What I would like to do is to build one tar/zip containing the jars (and dependencies) of all subprojects. I have defined an assembly descriptor only in the parent project. This descriptor defines a fileset for each subproject. Each fileset identifies the files I want to pick up from that particular subproject. This works fine. But since this is a multiproject build, after building the parent project, m2 tries to run the assembly goal the subprojects(modules) and fails (right now this is not an issue for me). I guess the way the assembly pluginis meant to work is to have individual descriptors for the subprojects(I suppose they could be empty descriptors in my case). is this understanding correct? I haven't got the dependencies to be included as yet. My question is - are the dependencies that the assembly plugin expects to be defined in the dependencyset element specific to that project or can I define the dependencies at the parent project level itself, even if they are really dependencies for the sub projects. Thanks Sid Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - 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: [m2] repositories entry is being ignored
Offline means remote repositories (even file ones) will be ignored. The error message is misleading because it seems to indicate it tried :) - Brett On 8/14/05, Jason Grant [EMAIL PROTECTED] wrote: I have a repositories entry that seems to be ignored, since it produces the following output: --- [EMAIL PROTECTED] eclipse-libraries]$ m2 --offline install [INFO] Maven is running in offline mode. [INFO] [INFO] Building Eclipse libraries [INFO]task-segment: [install] [INFO] [INFO] maven-install-plugin: resolved to version 2.0-beta-1-SNAPSHOT from local repository [INFO] maven-install-plugin: using locally installed snapshot [INFO] maven-plugin-parent: using locally installed snapshot [INFO] maven-assembly-plugin: using locally installed snapshot [WARNING] * Using defaults for missing POM org.eclipse:libraries:pom:3.1 * [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Main Error: Unable to download the artifact from any repository org.eclipse:libraries:3.1:zip from the specified remote repositories: http://repo1.maven.org/maven2 Path to dependency: 1) net.agentis:eclipse-libraries:pom:1.0-SNAPSHOT 2) org.eclipse:libraries:zip:3.1 Root error: Unable to download the artifact from any repository --- An extract from my pom is: repositories repository idcentral/id nameCentral Development Repository/name urlfile://localhost/home/jas/agentis/repo/central/url snapshotPolicyalways/snapshotPolicy /repository /repositories dependencies dependency groupIdorg.eclipse/groupId artifactIdlibraries/artifactId version3.1/version typezip/type /dependency /dependencies --- I think the integrity of my repository is OK - it has the format shown below. (I've also tried putting a repository directory above org). I've tried the libraries-3.1.pom file with both packaging of 'pom' and 'zip', but no joy. Maybe m2 doesn't support depending on zips? /home/jas/agentis/repo/central/ |-- org `-- eclipse |-- libraries `-- 3.1 |-- libraries-3.1.pom `-- libraries-3.1.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Management - Need advice
Ok, there are a few ways to attack this. 1) dependency mangement, as you say. 2) hold each of the dependencies at snapshot. This will effectively do what you want, but that build won't be reproducible. 3) use a range. Again, not reproducible, but means you can get the latest release instead of just development versions without having to update the data (so have the freedom to bless which one will be used) We're still working on full support for (3). It sounds to me like you want (2), and want your nightly build to run the release plugin, and have it tag the project and update all the internal versions. - Brett On 8/14/05, dan tran [EMAIL PROTECTED] wrote: Hello all, I am going to have a m2 build system that contains lots of sub projects. my daily build uses the same version of all sub projects. and the version is incremented for each daily build. In M1, I use one global version property in project.properties of the master project root. For each daily build, the system increments the version in properties and tag the entire source tree. In m2, it seems that the only way to achieve this are: - Define all possible sub projects in dependencyMangement at the root pom or - I need to write a plugin to transerse to all subproject and change the version in poms and their dependencies,check in all the changes before the build Each has its own complexities that I wish to avoid I also notice that m2 and continuum builds also have to go thru my scecario for each new release ( offical alpha, beta,etc). Is there a better way? Or the capability is already there in M2. -Dan - 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: [m2] repositories entry is being ignored
Whoops pasted a 'clutching at straws' experiment by mistake. The problem is manifest without the offline switch too. In that case, I don't understand why it goes to repo1.maven.org when I'm trying to tell it otherwise in my pom. Output below. J. [EMAIL PROTECTED] eclipse-libraries]$ m2 install [INFO] [INFO] Building Eclipse libraries [INFO]task-segment: [install] [INFO] [INFO] maven-install-plugin: resolved to version 2.0-beta-1-SNAPSHOT from local repository [INFO] maven-install-plugin: using locally installed snapshot [INFO] maven-plugin-parent: using locally installed snapshot [INFO] maven-assembly-plugin: using locally installed snapshot Downloading: http://repo1.maven.org/maven2/org/eclipse/libraries/3.1/libraries-3.1.pom [WARNING] Unable to get resource from repository http://repo1.maven.org/maven2 [WARNING] * Using defaults for missing POM org.eclipse:libraries:pom:3.1 * Downloading: http://repo1.maven.org/maven2/org/eclipse/libraries/3.1/libraries-3.1.zip [WARNING] Unable to get resource from repository http://repo1.maven.org/maven2 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Main Error: Unable to download the artifact from any repository org.eclipse:libraries:3.1:zip from the specified remote repositories: http://repo1.maven.org/maven2 Path to dependency: 1) net.agentis:eclipse-libraries:pom:1.0-SNAPSHOT 2) org.eclipse:libraries:zip:3.1 Root error: Unable to download the artifact from any repository [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Sun Aug 14 13:53:04 EST 2005 [INFO] Final Memory: 1M/3M [INFO] You have mail in /var/spool/mail/jas On Sun, 2005-08-14 at 13:13 +1000, Brett Porter wrote: Offline means remote repositories (even file ones) will be ignored. The error message is misleading because it seems to indicate it tried :)
