Re: Building a project and it's SNAPSHOT dependencies
Wim,
Could you post your resulting goal(s) here so that others seeking to do
the same can benefit from your work ?
Thanks,
Jim
Wim Deblauwe [EMAIL PROTECTED]
06/15/2005 06:34 AM
Please respond to
Maven Users List
To
Maven Users List users@maven.apache.org
cc
Subject
Re: Building a project and it's SNAPSHOT dependencies
ok, thanks got it working now.
2005/6/15, Vincent Massol [EMAIL PROTECTED]:
Ok, I understand. Well, you can still use the maven:maven tag...
-Vincent
-Original Message-
From: Wim Deblauwe [mailto:[EMAIL PROTECTED]
Sent: mercredi 15 juin 2005 10:00
To: Maven Users List
Subject: Re: Building a project and it's SNAPSHOT dependencies
Well, I use the multiproject plugin, but this builds *all* modules. I
can ofcourse tweak this to include or exclude as many as I want but
this is not convenient for what I want.
I want to build a project with all it's dependent (and only it's
dependent modules, not others) snapshot dependencies. I want this to
be sure I have the latest of everything when I build my project. Note
that all my modules are at the same level:
+ modules
|
+ -- module1
+ -- module2
+ -- module3
Suppose module3 only depends on module1. Using multiproject would
build all 3. I want to have a system that when I am in the module3
directory, I tell maven to build with a special command and it would
first do a jar:install of module1 and of module3.
regards,
Wim
2005/6/15, Vincent Massol [EMAIL PROTECTED]:
Wim,
You should use the multiproject plugin for that. Now to do what you
want
you
need to use the maven:maven tag to spawn a maven process.
-Vincent
-Original Message-
From: Wim Deblauwe [mailto:[EMAIL PROTECTED]
Sent: mercredi 15 juin 2005 09:07
To: Maven Users List
Subject: Building a project and it's SNAPSHOT dependencies
Hi,
I'm writing a jelly script for building a project and also
building
it's dependencies in 1 go. I currently do this:
goal name=build:withdeps description=Builds your module
and
all
it's SNAPSHOT dependencies
ant:echoBuilding this module (${pom.id}) with all
it's
SNAPSHOT
dependencies/ant:echo
ant:echo message=There are
${size(pom.dependencies)}
artifacts for
this project/
j:forEach items=${pom.dependencies} var=dep
indexVar=depNumber
ant:echo message=Dependency ${depNumber}:
${dep.artifact}/
ant:echo${dep.version}/ant:echo
ant:echoSNAPSHOT present?
${dep.version.contains('SNAPSHOT')}/ant:echo
j:if
test=${dep.version.contains('SNAPSHOT')}
!--attainGoal
name=build:withdeps
/--
/j:if
/j:forEach
attainGoal name=jar:install/
/goal
This works to find out what modules need to be build, but then I
am
stuck. I want to start my goal build:withdeps in the directory
of
the dependency so that one gets build (and if it also has snapshot
dependencies, those get build first). Is there a way to do this?
regards,
Wim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
_
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo!
Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
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]
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo!
Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
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: Why I hate Maven :-)
Brett, Thank you for taking the time to put out a very concise and thoughtful response. As for the blog putting it out again, I think I trusted the search engines to much. I have searches that run each morning and one of them brought that blog entry up for the first time so I treated it as relatively recent. Jim Brett Porter [EMAIL PROTECTED] 06/14/2005 04:17 AM Please respond to Maven Users List To Maven Users List users@maven.apache.org cc Subject Re: Why I hate Maven :-) On 6/14/05, Jim Mochel [EMAIL PROTECTED] wrote: Brett Porter recently posted a BLOG entry asking why some people hate Maven. Hmmm.. unless I'm mistaken that was last year! Maybe the blog software decided to send out a refresh :) Regardless, you make some good points here - thanks for taking the time to do so. I've spent some time putting together a response, and have also put it up on the blog as I think it would be of general interest to people who have read the original post. http://blogs.codehaus.org/people/brett/archives/001110_re_why_do_you_hate_maven.html Im happy to discuss any of these points further, or examine your SOA use case in more detail WRT Maven2 if you'd like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why I hate Maven :-)
Brett Porter recently posted a BLOG entry asking why some people hate Maven. I couldn't get the blog entry dialog to take more than two sentences so I figured I would post it here. Please read this without assuming that I am attacking Maven 1x. I clearly like something about Maven since I am still using it. Keeping in mind that much of this looks like it is being solved by M2 here are some of my all time greats hassles: ISSUE: Multiproject handling is a tacked on option whose interaction with other goals becomes problematic. M2: Appears to have been addressed in M2. ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion. M2: Appears to have been addressed in M2. ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals. M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation. Ideology - More often than not, If Maven's best practices doesn't fit my real world issues I am screwed. The workarounds take much more time than they might (aggravated by lack of documentation issues) and almost always cause bad side effects.. Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets. ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment. There are circumstances here at my site with an SOA deployment which means that EVERYDAY we deal with the negative impact of those features. We can have all unit testing OR none AND we have to write all of our own code to manage the issues many of which could have been avoided if we had a way to run the tests as a process after we had successfully built, installed, and did a deploy to the app servers. Yes, we have workarounds and they are not ideal. M2: I am not yet clear that this is resolved in M2. ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. At one point I was giving developers a process that had them creating 8 projects for each service to be deployed even though the actual source code was 3-11 files per service. This was necessary so we could manage the generation of key elements and unit tests. In effect, the source code was the same but it had several expressions in the world at large and each one required a separate project. Now we currently put it all in one project and I have created a group of rules to generate ALL the artifacts for a single service from the one project. It doesn't fit perfectly with the existing other practices inside Maven but it gives my fellow developers a lot less complexity to manage and thus there are a lot fewer mistakes along the way. The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference. M2: I have seen no sign that this is simpler in M2. ISSUE: The versioning of artifacts is VERY much a one size fits rarely UNLESS you are in total control of all of your codebase. If there is any place where a specific artifact name doesn't work or cannot contain a version at deployment time (.NET strongly named assemblies come to mind - painfully) then there are rarely workarounds that don't take many hours to implement and integrate into the process. M2: I have seen no sign that this is simpler in M2. ISSUE: Repositories assume WORA semantics for the artifacts. Building systems that require special dependencies for one platform but not for another is problematic. M2: This appears to be handled at the repository side by the new M2 repos structure. I am not clear about the use of Maven to build multiple configurations. ISSUE: Using multiple source paths in a single projecty is a headache. It has most often come up in the code generation arena but also when dealing with tools that require the source tree to be processed to be available AND cannot filter the source files to be processed by package name. M2: I am not sure if this is addressed in M2. Thanks for listening, Jim Mochel
RE: Why I hate Maven :-)
Chris, Thank you for the comment. Integration is indeed another issue. Unfortunately , even our base services need to be deployed into a container before testing. The proxy generation has to occur at the same time for reasons specific to the way another group choose to design the SOA. LOL. Jim Stevenson, Chris [EMAIL PROTECTED] 06/13/2005 11:28 AM Please respond to Maven Users List To 'Maven Users List' users@maven.apache.org cc Subject RE: Why I hate Maven :-) Jim, On your point about SOA and Maven. We have the same problem at my company. But you have to remember that the unit tests are to test the unit of deployment and its code. It sounds like what you're doing is integration testing (proxy code - server code) which is a different kettle of fish. We are thinking of getting around this using mock objects to actually test the proxy code and creating a custom project of integration tests which will be built separately when all the code has been deployed. Chris -Original Message- From: Jim Mochel [mailto:[EMAIL PROTECTED] Sent: 13 June 2005 16:15 To: Maven Users List Subject: Why I hate Maven :-) Brett Porter recently posted a BLOG entry asking why some people hate Maven. I couldn't get the blog entry dialog to take more than two sentences so I figured I would post it here. Please read this without assuming that I am attacking Maven 1x. I clearly like something about Maven since I am still using it. Keeping in mind that much of this looks like it is being solved by M2 here are some of my all time greats hassles: ISSUE: Multiproject handling is a tacked on option whose interaction with other goals becomes problematic. M2: Appears to have been addressed in M2. ISSUE: The Clean goal isn't clean. Requires all dependencies to be available before deletion. M2: Appears to have been addressed in M2. ISSUE: The majority of the functionality is undocumented and therefore, inaccessible at speed. With the exception of a _small_ number of _core_ tasks there is almost no documentation. I currently have all the plugins expanded in a subdirectory so that I have an online dictionary of jelly and java code and properties and goals. M2: It may or may not be addressed in M2 but it looks like the basic explanantions of lifecycle are there and it looks like it may be easier for me to help update the documentation built on top of that foundation. Ideology - More often than not, If Maven's best practices doesn't fit my real world issues I am screwed. The workarounds take much more time than they might (aggravated by lack of documentation issues) and almost always cause bad side effects.. Maven's best practices often don't address corporate real world headaches. Even when I agree with them I bump up against the problems inherent with what an existing corporate practise and/or current tool sets. ISSUE: The attaching of the test and install goals in such a way that they cannot be separated easily and cleanly AND The assumption that testing can occur immediately after compilation and installation... without a deployment. There are circumstances here at my site with an SOA deployment which means that EVERYDAY we deal with the negative impact of those features. We can have all unit testing OR none AND we have to write all of our own code to manage the issues many of which could have been avoided if we had a way to run the tests as a process after we had successfully built, installed, and did a deploy to the app servers. Yes, we have workarounds and they are not ideal. M2: I am not yet clear that this is resolved in M2. ISSUE: The one project, one artifact rule is a great rule for configuration management BUT it puts the onus of managing complexity on the developer rather than the tool. At one point I was giving developers a process that had them creating 8 projects for each service to be deployed even though the actual source code was 3-11 files per service. This was necessary so we could manage the generation of key elements and unit tests. In effect, the source code was the same but it had several expressions in the world at large and each one required a separate project. Now we currently put it all in one project and I have created a group of rules to generate ALL the artifacts for a single service from the one project. It doesn't fit perfectly with the existing other practices inside Maven but it gives my fellow developers a lot less complexity to manage and thus there are a lot fewer mistakes along the way. The ability for a project to be able to register that it produces N artifacts and list those artifacts, ids, types, etc, would make a huge difference. M2: I have seen no sign that this is simpler in M2. ISSUE: The versioning of artifacts
Re: [Mavenbook.org] What content would you like to see?
I believe this is for documenting Maven 1.x , correct ? If so, I would suggest some sort of documentation about the different scopes and namespaces of ANT Properties, Maven Properties. the POM attributes, and the Jelly variables. A lot of trial and error and walking through 100s of mailing list emails went into discovering what worked in getting a POM variable into a property or a Jelly variable anbd determing which are visible to whom. I consider the http://wiki.astrogrid.org/bin/view/Astrogrid/UsefulMavenNotes note to have saved me HOURs of walking through plugin source to make things happen so most of those tricks I would actually hope that you would forsake documenting 1.x for maven 2.0. My reasons really boil down to Maven 1.x feels like a proof of concept and Maven 2 has already (in its Alpha version) eliminated almost all of the workarounds I had to implement to make 1.x work on my projects. Please take that has kudo's for 2.0 rather than slamming 1.0 Jim Mochel Vincent Massol [EMAIL PROTECTED] 06/07/2005 01:40 PM Please respond to Maven Users List To 'Maven Users List' users@maven.apache.org cc Subject [Mavenbook.org] What content would you like to see? Hi there, Tim O'Brien and I have started a web site called http://www.mavenbook.org. One of its goal is to advertise the Maven: A Developer's Notebook that we have written for O'Reilly. However the other goal is to publish other information about Maven. ATM we have 3 types of information there: - News about the book and more generally news about Maven appearances Tim and I will be giving. We are happy to broaden this for any presentation that anyone may give about Maven. But we'll need your help for this so that we know when it happens. - Tips and tricks about Maven. Tim and I are regularly publishing but again if you have a good tip that you'd like to post, contact me and I'll give you direct access to the wiki (yes, it's a wiki under the hood. Cool, no? ;-)). - Announcements. Maven releases and Maven plugings announcements I'm curious to know if you find those 3 categories interesting or not. For example, I'm not sure the announcements category is useful. What do you think? Also are there are any other category of information you'd like to see there. The idea is not to duplicate the resources that you see on the main maven web site. It's more oriented towards news than towards information or resources (this should be added on the main maven site). Thanks a lot -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] How to improve the documentation for the next generation.
To those people that are tackling the Maven 2 documentation I just wanted to throw a note your way: I have been moving off of supporting a Maven based build system and watching another guy take it on and his learning curve has made me realize that there is one thing that could speed the learning process. When you are reading on the properties of a plugin it would be very useful to have links to the maven global properties so that you can jump back and forth looking at the interactions. Thanks Jim Mochel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven2: dependencies with non-conformant file names.
Just chiming in for the first time since I started using Maven 1 (Other than asking new user questions). I have had a love/hate relationship with Maven ever since I started using it on a large project integrating the output of 4 different development groups. One of the things that has constantly frustrated is the way the enforcement of best practices interferes with the integration with tools that don't follow those best practices or interferes with the integration of existing Corporate best practices differing from Maven's own. Maven 2 already appears to have switched things over so that Maven's best practices are the easiest route to go, but not the only one. So when I deal with a tool that mandates that Jar names not contain a '-' I can make it all work. It looks like you have beaten the adages about 2.0 rewrites. Congratulations and thank you! Jim Mochel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: best practice with Eclipse?
One Subproject = One Eclipse Project \toplevel \root\project,.xml \subproject1\project.xml \subproject2\project.xml Etc. Use extends to have all the subprojects inherit from the common root project.xml run all the multiproject goals from. With the new Eclipse 3.1M5+ you can do a bulk import of all the subprojects and you can use multiproject:goal with -Dgoal=eclipse to generate the .classpath and .project files. It works pretty well Jim Mochel -Original Message- From: Jamie Bisotti [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 13, 2005 9:33 AM To: Maven Users List Subject: Re: best practice with Eclipse? I'm currently doing the latter...though I'd love to hear of a better way. Jamie On 4/13/05, Aaron Bell [EMAIL PROTECTED] wrote: I am just getting started with Maven. Can anyone advise a practical way to use Eclipse on a Maven project with multiple subprojects? For example, are people using a separate Eclipse Java project for each subproject, or a single Java project for the whole hierarchy? The former is implied as the 'eclipse:eclipse' goal (run on the top level) generates .classpath and .project files for each subproject. If I use a single Eclipse project for the whole lot, I then have the problems of: a. merging the .classpath dependencies from each subproject into the top level .classpath b. managing *many* source locations in the Build Path Thanks - Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jamie Bisotti Software Engineer Lexmark International, Inc. - 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]
How can I disable the hibbernate plugin ?
-- WARNING: Plugin 'maven-hibernate-plugin' is already loaded from maven-hibernate-plugin-1.3; attempting to load maven-hibernate-plugin-1.2 Attempting to download xerces-2.4.0.jar. - When using Maven , it periodically pulls down the xerces parser from somewhere other than the defined remote repository (which does not contain the xerces package) and this causes multiple problems with a tool used within the build. I don't use the hibernate plugin and woiuld like to disable the pulldown, how do I do it? Thanks Jim Mochel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mysterious Spaces in a genearted file (attributes like groupId ar e have spaces around them)
In Maven.xml I am using some information about dependencies to generate an
additional deployment descriptor for some services
The key line is:
x:element name=home
${pom.package}.${dep.groupId}.ejb.Home
/x:element
I expect it to generate something like:
homecom.ascential.analytics.services.examples.ejb.Home/home
But instead it generates:
homecom.ascential.analytics . services.examples .ejb. Home/home
Does anyone have any idea how I can trim these down ?
Thanks,
Jim Mochel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
