Re: Version ranges not working
I agree with Richard, as they exist now in maven version ranges can be used very effectively. I'm happy to post example projects if you want to know how to do it. If you want 'repeatability' then ranges might not be for you but if you want determinism and releasability then ranges are for you. Its just a matter of having good process and leveraging the tools to there greatest effect, rather than trying to make the tool perfect. On Sat, Sep 29, 2012 at 11:16 AM, Richard Vowles rich...@bluetrainsoftware.com wrote: You may then be surprised to know that there are many of us for whom version ranges in Maven work perfectly. Ideally Maven could be more clever and understand that [1.6.2] is already on the local system and the metadata checking for ranges doesn't need to be re-fetched, but that is merely an optimisation. SNAPSHOTS work perfectly, ranges work perfectly, and SemVer is a silly waste of space. Richard On Sat, Sep 29, 2012 at 2:07 AM, David Hoffer dhoff...@gmail.com wrote: I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. -- --- Richard Vowles, Grails, Groovy, Java Consistency is the last refuge of the unimaginative - Oscar Wilde ph: +64275467747, linkedin, twitter:richardvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com
Re: Version ranges not working
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.
If you care at all about agility being explicit everyone is very
cumbersome, the fundamental aspect is determinism - meaning that its
obvious WHY it behaves the way it does, once you understand how maven
implements ranges its very easy to use to them to great effect.
Having said that using ranges can be dangerous hence the composition
pattern mentioned in my previous email.
When you say nail down your version do you use [1.7.1] or 1.7.1?
On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS m...@batmat.net wrote:
+1.
Version ranges are basically just a bad practice in my experience. I mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)
So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.
Cheers
2012/9/28 Stephen Connolly stephen.alan.conno...@gmail.com
Well that is a recipe for disaster. rules only make sense within the
scope
of the artifacts they apply to.
This is kind of why version ranges are next to useless from a practical
PoV
anyway
On 27 September 2012 23:05, Paul French paul.fre...@kirona.com wrote:
I would only want the same version rules applied to all artifacts, not
on
a per artifact basis, that would be a nightmare! I understand that
people
who produce artifacts have their own versioning rules. However we can
take
that into account in our version ranging.
Usually for 3rd party artifacts we have a very narrow version range
since
we cannot trust the producer of that artifact not to break their
current
API in later versions unless they support semantic versioning.
On 27/09/2012 22:29, Stephen Connolly wrote:
when is that class applied?
each dependency would have its own comparator, as each dependency has
its
own versioning rules.
and then don't start on epoch's (i.e. where the versioning rules
change
from under your feet mid sequence
It's tempting... but dangerous... the closest I have come up with is
the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.
-Stephen
On 27 September 2012 22:19, Paul French paul.fre...@kirona.com
wrote:
Okay I see the problem.
How about allowing a user to plugin a Version class that implements
Comparator
class MavenVersion implements ComparableMavenVersion
{
public int compareTo(MavenVersion o)
{
// your implementation
}
}
Then we can all do whatever we need.
On 27/09/2012 21:40, Hervé BOUTEMY wrote:
I understand that many people get caught
But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?
The actual semantic is pure mathematical range, including or
excluding
an
extreme
since 1.8-alpha1.8-beta-1.8-rc1.8-SNAPSHOT1.8, it's pure
math
IMHO, anything that doesn't conform mathematical range will have
some
unexpected behaviour sometime
Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a),
[1.7,1.7.999]
Or we need to create another notation and define its semantics
precisely
Regards,
Hervé
Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :
+1
I agree with Jesse.
A version range like [1.7,1.8) should exclude any artifact that
starts
with 1.8
Then maven (or aether) would respect semantic versioning rules.
We use version ranges/semantic versioning and API analysis to
ensure
our
artifacts are versioned correctly. Sometimes we get caught out by
what
Jesse outlined below.
On 27/09/2012 15:51, Stephen Connolly wrote:
On 27 September 2012 14:41, Jesse Long j...@unknown.za.net
wrote:
Dear Maven Community,
I am writing to beg you to fix the problems with the version
ranges
in
Maven 3.0.5, specifically regarding the defining compatible
version
ranges.
I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility
range
as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
define
the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api
version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but
Re: Version ranges not working
For a practical solution... I just stopped using 0's in versions.. maven interprets 1.8 as 1.8.0 then [1.7,1.8) will never match 1.8.1-SNAPSHOT invariably you don't actually want a third parties release to affect you build because what they consider and breaking change might not be for you therefore you need your own lifecyle for the external dependency. I use composition poms for slf4j it looks like this... http://search.maven.org/remotecontent?filepath=net/stickycode/composite/sticky-composite-logging-api/2.1/sticky-composite-logging-api-2.1.pom All my projects depend on the composite at [2,3) and as I control the lifecycle it always works. I can upgrade the version across all my projects with a new release of the composite. You may note the two point version... personally I don't bother with the patch version, two points is enough, if you break it change the major version and if you don't change the minor. my 2c Michael
Re: Release version numbers in large multi-module project
IMO dependencies should never be inherited the results are always fuzzy, consider Parent P with defines a dependency on A 1.1 and Parent P' that defines a dependency on A 2.1 And a war project W that depends on two projects one with parent P and the other parent P'... which version of A should you end up with? Even if you have an answer to this question does it actually make sense? OO teachs us to inherit functionally and compose dependencies. The simplest solution and most consistent is to define compositions As an aside every linux distribution uses ranges to define package relationships, because it works and really could not be done any other way. We are talking debian, ubuntu, gentoo, redhat, suse etc why should dependencies in java be any different? Michael On Tuesday 21 September 2010 16:35:16 Anders Hammar wrote: The user of the module can always control this through a dependencyManagemet section. That's how it should be done. Ranges have all sorts of strange impact, IMO. One would be that your (and the user's) builds are not necessarily reproducable; the outcome might change should a new version of clojure be released. I strongly argue that you should declare a dependency to a specific version (likely the latest available) and let the end user handle any change to this. /Anders On Tue, Sep 21, 2010 at 02:21, Stuart Sierra m...@stuartsierra.com wrote: Hello, Maveners, I'm managing the build for clojure-contrib, a diverse collection of libraries for the Clojure programming language. After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself. Here's the catch: most modules will work with any version of Clojure; the user of the module should be able to choose. I want the parent module to have a dependency on Clojure with a range like [1.0.0,2.0.0). Aside from maven-release-plugin complaining about SNAPSHOT dependencies, are there any negative implications to doing this? Or am I doing it wrong, should I be using some other mechanism to manage this type of dependency? Thanks, -S - 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: SNAPSHOT versions Vs. incremental versions
On Monday 20 September 2010 21:50:30 Perez Ronen wrote: 1) Do you agree with me that the SNAPSHOT way is better? No you can achieve the same and more with releases and version ranges. 2) Can you give your reasons of why this is better? When integrating artifacts against a snapshot its meaningless just like giving a tester snapshots is meaningless the result is not deterministic. By specifying a range you are defining a constrained but flexible relationship which can be checked. For example this works fine War 1 depends on B 1.1-SNAPSHOT and C 1.1-SNAPSHOT B depends on A 1.1-SNAPSHOT C depends on A 1.1-SNAPSHOT But what if you have many wars War 2 depends on B 2.1-SNAPSHOT and C 3.1-SNAPSHOT B 2.1-SNAPSHOT depends on A 2.1-SNAPSHOT C 3.1-SNAPSHOT depends on A 3.1-SNAPSHOT might give you 3.1-SNAPSHOT or 2.1-SNAPSHOT when really it should be an error. I use War 2 depends on B [2,3) and C [3,4) with B 2.1-SNAPSHOT depends on A [2,3) and C 3.1-SNAPSHOT depends on A [3,4) gives you a conflict someone tried to merge 2 incompatible versions of A i.e. line 2 and line 3. I'm not sure why more people don't suffer these headaches, maybe they don't have large enough projects or enough deliverables. Most of the projects I work on delivery several wars with many shared artifacts. If thats not enough consider, one of the biggest hassles I used to have on projects was people checking in broken code, that would stop other developers from working. With snapshot dependencies you have exactly the same problem but worse as you don't need to update or you do. Finding a stable combination of snapshots and updated working copies is hard and prone to error. If you require that a developer release artifacts before you see their changes 1) if it breaks you just change your deps to use the previous version till they fix it 2) people are not afraid to commit code as someone has to release an artifact before its shared 3) continuous integration tools can check the head to head and head to latest releases for each artifact Thanks, Ronen. This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Technology or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: secur...@comverse.com. Thank You. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges
you must have valid metadata to use ranges... did you install the jar into your local repository? On Thu, 12 Mar 2009 08:37:51 Johannes Schneider wrote: Hi, I have a problem with version ranges. I try to compile Spring Rich Client Platform. There is a dependency to Jide defined: [2.2.0, 3.0.0) In my local repository there is the version 2.2.7 located. But compiling fails with this message: No versions are present in the repository for the artifact with a range [2.2.0,3.0.0) com.jidesoft:jide-action:jar:null When I change the version to 2.2.7 manually, everything works fine. Could anyone give me a hint how to solve this? Thanks, Johannes - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Michael McCallum Enterprise Engineer mailto:gho...@apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Decrease War size, to Decrease Deploy time
You could use rsync to copy the war Also don't explode the war, much faster deployment On Mon, 09 Mar 2009 05:19:24 Prag wrote: I have the following situation: I have a dev machine and a server machine running Tomcat. When Maven creates a WAR on the dev machine, it has to be transferred to the server, which takes some time due to all the libraries in the WAR. Is there a way to decrease this time? Maybe there somehow is a way to let Maven manage the library depencencies on Tomcat so that not all libraries have to be transferred every time? Possibly using other tools? -- Michael McCallum Enterprise Engineer mailto:gho...@apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.9 - internal repository - archetype plugin version help
-archetype-plugin/artifactId/metadata In the directory above (.m2\repository\org\apache\maven\plugins) the same xml file is generated with this output: ?xml version=1.0 encoding=UTF-8?metadata / I'd be most grateful for any comments because while I have something working, it would be more comforting to have it working in a manner where it can determine the RELEASE version automatically from my internal repository. Regards, Ross. _ Cut through the jargon: find a PC for your needs. http://clk.atdmt.com/UKM/go/130777504/direct/01/ -- Michael McCallum Enterprise Engineer mailto:gho...@apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:perform blowing up?
On Wed, 26 Nov 2008 16:13:32 David C. Hicks wrote: Have you tried using the eclipse:eclipse plugin? That's how I'm talk about the hard way... eclipse:m2eclipse... and install the m2eclipse plugin... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Not happy with maven (suggestion)
You have put a lot of effort into this email and its really important to spread the ideas around, could you put these issues into jira with suggested solutions? To give more visiblity. cheers -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Management Questions
I would highly recommend you externalise environmental configuration such that you don't need to rebuild any artifacts when moving them from one environment to another. On Fri, 07 Nov 2008 08:46:31 Hayward Lam wrote: Hi all, We have in-house maven projects. The build requires environment specific property replacement (i.e. dev, qa and prod) and we set up profiles for them. When the project has been tested and is ready for release, we can deploy the artifacts (dev, qa and prod) to our internal maven repository. My questions are: 1) Is there some sort of release management tool that can automate this process? 2) We use Hudson for continuous integration. The configuration will be based on each environment only (i.e. -P env-dev). So, each build will have its own build number. Is there some consolidated way to do this? i.e. same build number for dev, qa and prod. 3) What is the practice that works for you? Thanks -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2.0.7 reorders dependencies during build causing compilation failures
did you ever think that something is seriously wrong if the classpath ordering causes your build to fail? That could mean that sometime somewher someone will deploy your application and use a different order for the jars and it just won't run and the poor developer/ops person will have no idea... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plugin : Update RELEASE versions to actual release version during prepare
the release plugin generates a resolve pom that it commits to the tag... that has the actual version... there are caveats to its use like: it does not preserve exclusions and removes ranges but other than that it should be ok On Fri, 17 Oct 2008 07:22:25 Hayes, Peter wrote: We are considering trying to use the special RELEASE version in our pom files. I think in order to generate reproducible builds though the RELEASE version needs to be locked down to the actual latest release version as specified in the metadata. Once the release has been performed, the version change should be reverted back to RELEASE. Is this part of the release plugin functionality? Peter Hayes http://www.linkedin.com/in/petehayes Architecture Shared Technology Services | Fidelity Investments Management Technology -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: can't rev the version of multi-module project
I would recommend not using modules to do the release... just release each
project independently...
if you find version management becomes an overhead then use ranges to make it
a bit simpler...
On Fri, 17 Oct 2008 09:16:03 Johan Lindquist wrote:
Hi,
I have a similar setup, only I declare the dependency versions in the
parent pom (using dependency management). Of course, not tried to use
a property there
(define the versions explicitly), but maven happily updates the
dependency management section when releasing.
Cheers,
Johan
Ryan Heaton wrote:
Thanks, that helps, but the build still fails on the install with the
same error because child3 still depends on child1 which isn't
installed yet.
However, this does somewhat simplify my procedure...
New procedure:
1. mvn release:prepare (build will fail with message described
below, but the pom versions will be updated)
2. for each module, in order: mvn -N -DskipTests=true install
3. mvn release:clean (clean up the last failed release)
4. mvn release:prepare (should work this time)
5. mvn release:perform
Again, if anyone can help simplify this process (especially step #2
above), please let me know.
Thanks,
-Ryan
On Thu, Oct 16, 2008 at 1:59 PM, Stephen Connolly
[EMAIL PROTECTED] wrote:
do mvn -N install in the parent folder first and then mvn install
2008/10/16 Ryan Heaton [EMAIL PROTECTED]:
Well, my show had to go on. I had to resort to revving, building and
deploying each module one-by-one. Ouch!
If anyone can bring relief to my suffering, I would be greatly
appreciative.
-Ryan
On Wed, Oct 15, 2008 at 12:46 PM, Ryan Heaton [EMAIL PROTECTED]
wrote:
Hi.
I just converted my project to a Maven build. I started with version
1.8-SNAPSHOT of my project and I'm trying to cut a release for version
1.8.
My project is quite complex: multi-module and modules have
dependencies on one another. So to make it simple, there's the parent
with 3 child modules: child1, child2, and child3. All children inherit
from the parent module. child1 has no dependencies, child2 has a
dependency on child1 and child3 has a dependency on child2.
So, when I cut a release, all pom files are updated to the new
version, 1.8. The child poms, since they don't explicitly declare a
version, are updated to 1.8 by changing the inheritance of the parent
to version 1.8. The dependencies of the child poms are updated because
they're using a property reference, ${project.version}, to declare
their dependencies on their siblings.
But now I try to do a local install and get the dependency can't be
resolved but has been found in the reactor message and the build
fails because child3 can't resolve its dependency on child1 version
1.8.
Is my issue the same as http://jira.codehaus.org/browse/MNG-3685 ?
If so, how do I get Maven 2.0.11 installed? If not, how am I supposed
to cut a release? Is my project set up wrong?
Thanks in advance.
-Ryan
-
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]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Recommended project structure.
why do you have snapshot versions for parents? On Fri, 17 Oct 2008 09:42:10 Raphaël Piéroni wrote: follow the trunk and there will be a multimodule project Regards, Raphaël 2008/10/16 Trevor Harmon [EMAIL PROTECTED]: On Oct 16, 2008, at 12:59 PM, Raphaël Piéroni wrote: For a good idea of a multi module project, you could refer to platina: http://platina.svn.sf.net/svnroot/platina/platina-archetype/ Doesn't seem to be anything there. Trevor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assembly Plugin
On Tue, 14 Oct 2008 07:08:27 David wrote: Is it possible to have two different descriptor files where one can be binded to a phase and the other only activated from the command line? Thanks, David you could probably do that with a profile, just specify the plugin in a profile but only with the descriptor configuration and do mvn -P other-descriptor-profile assembly:assemble -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing dependency in pom.xml using profiles
consider the in any situation where you want to change things based on flags
its gets complicated.
why not just have a separate artifact that is very simple for each scenario...
there might be a little more setup but it means for a maven aware developer
they know that you have 5 projects therefore 5 artifacts and if you say
install or package on them you can get five results...
now consider your profile scenario... how many profiles... how many
combinations... in order to understand any one of your projects a deveoper
would need to read and understand all the profiles...
On Sat, 11 Oct 2008 22:55:15 Stephen Connolly wrote:
I would think a better way would be to specify the different artifacts
as dependencies only in different profiles.
You can then just activate the profile for the artifact you want, and
everything is self-contained in the pom
2008/10/11 Brett Porter [EMAIL PROTECTED]:
mvn help:effective-* will show the profiles actually used.
This seems like a very bad idea for build reproducibility however - I
wouldn't recommend it.
- Brett
2008/10/11 Lucie [EMAIL PROTECTED]:
This is defined pom.xml:
dependency
groupIdgroupId
artifcactId${my.artifactId}/artifactId
vesion/version
/dependency
I have a profile defined in profiles.xml to pass the ${my.artifactId} as
a property at build time.
This doesn't work - no value is passed. What may have caused to failed?
Lucie
--
View this message in context:
http://www.nabble.com/Changing-dependency-in-pom.xml-using-profiles-tp19
927738p19927738.html Sent from the Maven - Users mailing list archive at
Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
-
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]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version conflict resolution and stable builds
On Thu, 09 Oct 2008 22:31:10 Michael McCallum wrote: theres a taste i probably missed something as this is just off the top of my head, yes i did don't use release poms if you expect version ranges to work... its just makes a mess of everything and gets rid of your carefully crafted exclusions... this might have been fixed i'd have to go and test... i should have opened a bug if there is not one but just worked around it for the time being -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version conflict resolution and stable builds
On Thu, 09 Oct 2008 12:47:13 Ian Robertson wrote: I'm actually curious if anyone knows the reason for this; it seams that a far better choice would be to choose the *lowest* version which matches all range requirements, so that builds could be temporally stable. ranges would be useless because they would never change, ultimately it assumes that you are converging on the goal and new releases are better... which is quite reasonable -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version conflict resolution and stable builds
Lets got back to the basics of development... you need to develop something to that is delivered to be run So by my way of thinking I want an acurate description of whats delivered and run such that I can reproduce it. Have the convention that versions are in the jar names and the pom and its properties end up in the jar facilitates this. But I also need to have a flexible develoment environment with low overheads. If I use best guess or open ranges I have no power to control things because i need to tweak poms all over the place. So my approach is a design and build by contract when i use the major version to indicate a contract... and all my ranges restrict a dependency to a single major version. e.g. a.b.c-1.5 depends on a.b.d with [1,2) This is arbitrarily simple see a more complex example attached Now what this means is that when you break your project down into its component pieces you can by convention relate them to other things stably. Not reproducibly but thats ok because its determinable. If you try to build your deliverable and there is a range conflict you get an error on build... you can't build a dodgy deliverable. With open version ranges or best guess deps you can end up with any released dependency! and even if you have a process to know when you got it wrong but its very difficult other than adding dependencies to the deliverable project to get it right. Now your developers need to make a call when they release - usually after discussion - is my change breaking - you can test this with CI - and if so should I increment the major version. If you get broken because they make a mistake you have options... roll back deps... release a new rolled back version... The funny thing I avoided most of the gotches due to my approach... Now the gotchas... 1) don't use modules 2) don't use snapshot parents or relative paths 3) inherit by function which means have parents that configure particular plugins and keep them simple and try to have a little as possible in children poms. i have a 2 deep hierarhcy with one root and 9 sub parents The convention i use to break projects down is by function that means I have api, model aka domain, strategy, composition, configuration, webapp, abstract webapp, webservice, repository. It means a proliferation of artifacts but at the same time a proliferation of reuse... 4) use a 2 point version major.release and always start at X.1 never at X.0 otherwise ranges don't work... its not a bug just an ideosyncracy... consider [1,2) this does not match 1.0-SNAPSHOT and matches 2.0-SNAPSHOT which seems odd... if you never make 1.0-SNAPSHOT or 2.0-SNAPSHOT then range boundaries work determinably. range calculations break down if have more that 3 points so you need to leave wiggle room. 5) save the third point for patches which are releases off branches 6) don't use dependency management it encourages bad inheritance, you can just use transitive dependencies and they are more flexible 7) wrap 3rd party dependencies with local projects that just enforce consistent resolution - they don't use ranges so you need to manage it theres a taste i probably missed something as this is just off the top of my head, gotta do some work now On Thu, 09 Oct 2008 12:47:13 Ian Robertson wrote: On Sun, 2008-10-05 at 04:48 -0600, Michael McCallum wrote: On Sat, 04 Oct 2008 14:16:57 Keith Branton wrote: 1. Can anyone please tell me of a way to achieve this with 2.0.9 today? With the appropriate use of ranges you can do this and it resolves as described. There are about 11 gotchas to doing it though, all worked around by appropriate conventions. Can you elaborate on what these 11 gotchas are, or point to a place which does? One of the biggest issues I see with ranges is that maven chooses the most recent version in the repository which matches a given range. Consequently, if a pom specifies a version range for a dependency like [1.5,), the exact same code can create different builds on different days if a new release of the dependency is made. I'm actually curious if anyone knows the reason for this; it seams that a far better choice would be to choose the *lowest* version which matches all range requirements, so that builds could be temporally stable. - Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'dependency'. WAGON_VERSION: 1.0-beta-2 [INFO] [INFO] Building Jis Products [INFO]task-segment: [dependency:tree] [INFO] [INFO] [dependency:tree] [INFO
Re: Generate list of plugins and their versions used in a build
mvn help:effective-pom On Thu, 09 Oct 2008 22:16:39 aman kohli wrote: Hi, For a build, I need to generate the plugins used and their versions. Is there a way to do this? Ideally something as simple as the effective-pom mechanism would be great. One mechanism would be to to use the plugin-registry, if there is a way to auto generate that. http://maven.apache.org/guides/introduction/introduction-to-plugin-registry .html thanks -- aman -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generate list of plugins and their versions used in a build
I can't believe you said that. :-/ Just fork the mojo and actually write the output to a file or even better patch the help plugin to 'attach' its output to the artifact. On Thu, 09 Oct 2008 23:03:37 Nick Stolwijk wrote: Couldn't you parse the output of mvn help:effective-pom? Or do you need another format? Maybe it could be another goal on the help plugin. What is your use case and what do you need? Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Thu, Oct 9, 2008 at 12:00 PM, Michael McCallum [EMAIL PROTECTED] wrote: mvn help:effective-pom On Thu, 09 Oct 2008 22:16:39 aman kohli wrote: Hi, For a build, I need to generate the plugins used and their versions. Is there a way to do this? Ideally something as simple as the effective-pom mechanism would be great. One mechanism would be to to use the plugin-registry, if there is a way to auto generate that. http://maven.apache.org/guides/introduction/introduction-to-plugin-regis try .html thanks -- aman -- Michael McCallum Enterprise Engineer mailto:[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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to rename or copy resource files when packaging war-file
why not externalise - as in not in the war - the configuration? because by inferrence you are talking about rebuilding your war file for different environments... how do you guarantee that its the same without a bunch of extra hassle? On Fri, 10 Oct 2008 03:27:04 Johan Hammar wrote: Hi! In my project I have two files, foo-dev.xml and foo-production.xml, in src/main/resources. When I package the project as a war-file I want to rename or copy one of those files to foo.xml. Which file to rename or copy depends on which profile I run maven with. Is this possible and where can I learn more about this? Regards, Johan Hammar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version conflict resolution and stable builds
On Fri, 10 Oct 2008 03:00:38 Zoltan Farkas wrote: I believe using dependencyManagement actually helps you... it gives you the power to control the dependency versions... in very simple cases it helps and with the import scope it can be quite useful but its more difficult to understand the result of depedency resolution. The issue I have is that depedency management is an attempt to force a version of a library but from outside of the resolution tree. It has side effects and ultimately it makes it harder to manage dependencies because it makes it easy consolidate all your version for a short term gain. For a small project it makes sense and works. For larger projects it does not. And I take the java view, fewer more well understood approaches to problems leads to better code sometimes more verbose but easy to understand. But even more than that when I manage versions of external libraries I just just manage versions, I also manage related libraries and exclusions and probably the most important: I provide an independent release cycle from the upstream projects which means all my projects can be exposed in stages to upstream releases. I fear that most of the things I say will make no sense to windows and linux users and a reaonsable portion of linux users who don't really understand how far package management has come and its parallels with maven. from the doc: very important use of the dependency management section is to control the versions of artifacts used in transitive dependencies --zoly -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency SNAPSHOT problem
What does stable mean? Ultimately the only thing that matters is that you are happy for testers to test it or users to use it. Don' t jt avoid given things version because its not stable. I just version everything and only Release some versions. Not sure how big you team is but consider... you release a snapshot and your colleague is like awesome new feature really needed that... works diligently... you realise theres a mistake and fix it - or even better someone else deploys from the same project with some different changes... you collegue finds that all of the sudden hes broken... and no way to go back... you spend x minutes/hours trying to resolve what should happen next. Now add 10 people with various project interelations... its unmanageable.. you might as well use ant and build everything from source. However if you use the release plugin and release rather than deploy then your collegues can choose when to upgrade and take the integration pain. There are two approaches pessimistic with fixed versions or optimistic using ranges back to work... On Fri, 10 Oct 2008 07:58:12 Qureshi,Shahzad [Ontario] wrote: Hi all, I'm working on a module that is a dependency of our main project. I created this module as a snapshot since its currently under development as well and its not a stable version yet. I upload it to our internal remote repository, however, whenever anyone updates their dependencies they don't get the latest version of my module, the copy still remains the same as the previous version until they delete their local copy of the dependency. This is a sample of my module's pom file project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdca.abc/groupId artifactIdlist/artifactId version1.0-SNAPSHOT/version namesome List/name descriptionXMLBeans created schema jar/description /project I use mvn deploy plugin to deploy this file (its an xmlbean created jar file if anyone cares to know). And this is what I use to deploy the jar file mvn deploy:deploy-file -Durl=scp://address -DrepositoryId=repo_id -Dfile=file.jar -DpomFile=pom.xml This part seems to be working fine since it creates a new jar file on the repo with a new timestamp everytime I deploy the new verison of my jar file, however the other users can't get the latest copy. This is the sample pom file of our main project project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdca.abc/groupId artifactIdqc/artifactId packagingjar/packaging version2.0/version nameQC/name build plugins plugin artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration source1.6/source target1.6/target /configuration /plugin /plugins /build repositories repository idrepo_id/id urlhttp://address/url /repository /repositories dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.3.1/version scopetest/scope /dependency dependency groupIdca.abc/groupId artifactIdlist/artifactId version1.0-SNAPSHOT/version scopecompile/scope /dependency /dependencies /project Any ideas? Or do I've the whole idea of SNAPSHOT wrong? Thank you -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't I define the parent pom's version is LATEST？
If you really really think about all of the implications this is one of worst conventions ever proposed, its bad enough that huge numbers of projects have snapshot versions for parents in source control which means you can never just check out one artifact and build it... you have to get the whole mess look at what xorg and kde are doing break everything down into discreet components that you can build independently... it reduces the learning curve, encourages reuse and makes it easy for people to contribute On Wed, 08 Oct 2008 16:20:16 陈思淼 wrote: I've vote for this issue, I think the automatic parent pom version range is reasonable request! -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency range resolution resolves to SNAPSHOTS!?
On Thu, 09 Oct 2008 01:20:42 Mark Hobson wrote: 2008/10/8 Stefan Fritz [EMAIL PROTECTED]: Hi all, We recently (during the last weeks) ran into a situation where version ranges (e.g. [1.0,) ) where resolved to SNAPSHOT versions as well. My understanding was always that if I specify a non-snapshot version in a where does it say that in the docs? Maybe I missed it. range that only released version will be resolved. Is my understanding incorrect or is there a bug in dependency resolution? I'm using 2.0.9 This is indeed a bug, see: http://jira.codehaus.org/browse/MNG-3092 I still disgree, its absolutely necessary for agile development. If you consider that every version just a number and you use interval notation then of course snapshots are going to fall into the range somewhere. The argument is 'are SNAPSHOTS really useful at all?' and the answer is 'they are but only when governed by appropriate development practice'. If you go and SNAPSHOT things all over the place and deploy them to remote repositories I would argue that you should just not use maven go back to make or ant because you have not made the transition to understand how powerful maven dependency resolution can be for development and _deploying_ with determinability. I stay away from reproducibility because thats the other end of the scale from agile and convention. My goal is to develop fast and know the result, potentially break but be able to recover from a break _very_ quickly. Carry out multiple lines of development without the need for costly source control merges. Branch and patch easily and always stay in a state of release readiness. You can do all of this without making the ramp up significant. To digress slightly when unit testing in order to be sure you are actually proving anything you can't have SNAPSHOTS with one exception if I as a developer injected that SNAPSHOT into the resolution tree for a reason i.e. to see if it breaks the test and why or not. If I have other peoples SNAPSHOTS I have no easy process for figuring out how and why things are breaking and how to achieve the fix, no way to roll forward and back to isolate faults. my 2[00] cents :-/ -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EclipsePlugin] downloading sources without writing .project and .classpath files
if you use m2eclipse then the .project files and .classpath files should be pretty much the same... i always put them in and thats been true of the last 3 large commercial projects i've worked on. In all cases the environments were mixed windows and linux... never had a problem On Thu, 09 Oct 2008 08:25:53 Nick Stolwijk wrote: And normally I exclude the .classpath and .project files from SVN. Each developers machine is different, so those files are also a little machine dependent. (plugins, filepaths, anything) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice for branching projects?
I would give you approach a big thumbs up with one exception... use [1,2-!) not [1.0.0,) otherwise you can't carry out concurrent development and patching... you need to be able to isolate the major version with ranges... oh and never start your version as 1.0 always start at 1.1 if you expect ranges to work properly... On Wed, 08 Oct 2008 14:22:34 Simone Gianni wrote: Hi Stefan, I don't know if I got the problem right and if this could be a solution, but I do as follows (obviously, we are talking about maven branching, not SVN or CVS branching, which is another story) : - setup a developers only maven repository - setup a production only maven repository - use range versions instead of fixed ones .. This means that instead of having a dependency on artifact com.yourcompany:artifact:1.0.0 you have a dependency on com.yourcompany:artifact any version 1.0.0 - when a subproject is buggy, a team (or single developer, or whatever) will start working on it - they will build it on their own computers (in their local repository), so no problem with them testing their own work - they will occasionally deploy it TO THE DEV ONLY repository .. deploying it there, will let the other teams use the new artifact and test that their own work is correct related to the new bugfixes/refactorings and so on .. obviously, when they deploy, they should increment the minor version/revision, but only on that project specific pom (for example 1.0.0-r1 1.0.0-r2 or 1.0.1 1.0.2 etc...) - when the bugs have been fixed, the deploy can be made on the production only maven repository - from there, a complete build and test of the application can be done, and final release (war, jars or whatever) created to send to customers This way, every project can have its own lifecycle, its own releases, and probably its own SVN branches and so on. While using fixed version dependencies is a good practice when linking to something outside your control (artifacts on the main repo), for internal dependencies (artifacts produced inside your company/team) it is a maintenance nightmare and most of the time useless, cause you know when a new version will break compatibility and can adjust versioning only when that happens. Using SNAPSHOTS can save a bit of time making the change the version when sending to other developers step not necessary, but I think that it should be avoided when there is a high number of developers : that step can potentially break the build and stop other developers' work if the new package breaks compatibility when it should not or introduces more bugs than the previous one (which obviously happens :) ), and having also these internal releases versioned is IMHO more time-saving than using automagic snapshot updates. Hope this helps, Simone -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: evaluation report-history tools (e.g. xradar, sonar)
http://qalab.sourceforge.net/ no experience but from having looked at the projects they all follow a similar flawed approach... store the results of runs in a database somewhere the tools are good according to people i know who have used them... On Wed, 08 Oct 2008 10:52:41 aldana wrote: hi, we need some historic tracking for metrics. for that i considered using http://sonar.codehaus.org/ and http://xradar.sourceforge.net/issue-tracking.html. before doing an evaluation, has anybody had good/bad experience with these products? or can you recommend any other similar tool? thanks. - manuel aldana aldana((at))gmx.de software-engineering blog: http://www.aldana-online.de -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version conflict resolution and stable builds
On Sat, 04 Oct 2008 14:16:57 Keith Branton wrote: 1. Can anyone please tell me of a way to achieve this with 2.0.9 today? With the appropriate use of ranges you can do this and it resolves as described. There are about 11 gotchas to doing it though, all worked around by appropriate conventions. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Couldn't find a version error
On Mon, 06 Oct 2008 08:53:04 buters wrote: 3. The problem is that my project isn't quite Maven project. It is RCP Project, that I want to build with Maven. I've created a simple Maven project with a dependency from org.eclipse.equinox.registry-3.4.0-v20080516-0950 and Maven has immediately found it. The error happens only if I try to build my RCP project, Maven cannot find this version in my local repository. %-| %-| %-| ranges are resolved from metadata you must have a valid maven-metadata-local.xml for range resolution to work... you should use install-file to install the file into your local repo not just copy it... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conditional dependencies
wrap the dependency for the db driver in a pom project that also depends upon the dialect e.g. example.company.db.posgresql - postgresql jdc driver - postgresql database dialect then example.company.applicationwithdb - example.company.db.postgresql profiles should not be used to munge up dependencies, it just makes it confusing for people to have side effects. On Mon, 06 Oct 2008 05:47:16 Simone Gianni wrote: Has anybody ever done something like this? Has anybody had the same need and investigated a way to solve it? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deterministic update of snapshots
deterministic and snapshot just don't go together... as the result of any update is non-deterministic and being able to undo an update if rather difficult. you can use range to achieve and agile deterministic release process where you can roll forward or back anytime you like but get the latest by default... assuming you have reasonable tests and some communication you rarely break people in this way On Thu, 02 Oct 2008 22:43:03 softwarepills wrote: If i am not wrong, with unique=false and policy=daily, snaphot updating follows this rules: 1.- Update check (and posibly update itself) is made a day after last publishing in the remote repository of the single artifact being checked. So it could be at any time, any day, and different for every artifact, as they are involved in the current build (not all artifacts at the same time at 12:00 pm, for example). 2.- As said in http://docs.codehaus.org/pages/viewpage.action?pageId=22585, every time a new remote snapshot is published, it will overwrite a local snapshot regardless of age. This is the only way to provide consistent behaviour and avoid clock skew - for example, while it might make sense to honour a local snapshot if it were newer than the remote snapshot, it may be that the local one was built from older sources and so is, in fact, older. For me, this could be very confusing in a team development process (especially 2). I think a deterministic way of snapshot updating is preferable using policiy=never. In this way you always preserve the same snaphots and, eventually, you can use -U to compile with fresh snaphost and get in sync with the team. Of course, you get a deterministic way of snaphot updating at expense of automatic updates, and posibilly, you can discover that one lazy developer has never used -U and is using very old snaphots. Please, any comments are welcome. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to let xmlbean generate jar file?
One might argue that questions that are answered easily by reading the documentation are SPAM. Theres lots of people reading this who can help people who have real problems. If you find the docs don't work quote them and tell us about the problems and we can help. http://en.wikipedia.org/wiki/Netiquette http://www.merriam-webster.com/dictionary/netiquette On Tue, 30 Sep 2008 22:00:42 Ram wrote: 2008/9/30 youhaodeyi [EMAIL PROTECTED] I use xmlbean plugin in a Maven project. When doing mvn xmlbeans:xmlbeans, it will generate source and classes but not jar. How can I let it produce jar file? -- -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best Practice for code generation scenarios in Maven
no you should generate into a new directory and add it as a source compile
root...
attach he plugin to generate-sources and it will be compiled and jar'd up just
like other code...
see the jaxb2 or xmlbeans plugins for examples...
On Wed, 24 Sep 2008 10:16:48 stug23 wrote:
I am currently porting an Ant-powered code generator to Maven and would
like to get input from this group for best practices with respect to code
generation in Maven.
Let's see if I have this right:
I wrote a Maven mojo to drive the code generator and can configure it in
the Maven project used for code generation.
I should always isolate the code generation into a single Maven module
(this could be part of a multi-module Maven project though) so that I can
declare the source directory for the generated code under the target
directory.
For example, something like this would be declared in the module where code
generation takes place:
build
sourceDirectory${project.build.directory}/codegen/java/sourceDirectory
...
...
The jar file artifact resulting from the code generation module would only
contain class files from the generator.
Since the standard src/main/java sourceDirectory/ has been 'usurped' by
the source directory where the code generator wrote its code, I shouldn't
have any other Java code under src/main/java.
Does this sound correct? Is this the best practice for a Maven module for
code generation? Does anyone on this group do this differently than what I
sketched out here? If so, why and what are the advantages of your
alternative approach?
Thanks in advance for your input!
:handshake:
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help Maven Release to SVN ERROR
So what you will find is that subversion is trying to copy from the working copy thats an older revision than on the server... just do svn up and mvn release:prepare again... the resume will work fine On Tue, 23 Sep 2008 07:51:03 Wendy Smoak wrote: On Mon, Sep 22, 2008 at 12:29 PM, Ryan Wong [EMAIL PROTECTED] wrote: Here is the svn http://dev.ave7.net/svn/java/common/trunk My Issue is when command mvn releaser:prepare There always an error like: ... If it's not just that the tag already exists, then some of the comments in this thread might be helpful: http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why am I not the boss of my own dependency versions???????
Is there any chance you can post a simple example... or perhaps the output of mvn dependency:resolve -X I use ranges in the way you are describing and do not and have not experienced any problems like that... however I have not dependencyManagement sections in any of my transitions... On Fri, 19 Sep 2008 10:19:49 sverhagen wrote: Hi. We've recently switched from one dependency strategy for our internal dependencies to another: - Old: all modules define dependency's without version's and inherit all the same parent with a dependencyManagement section that defines version's for all modules, e.g. as 0.0.7. - New: all modules define their own dependency's and version's as ranges, e.g. as [0.0.7,), and do no longer inherit a dependency management section We're slowly releasing this into our system. (We can't release everything at once, since a number of modules are worked on hence unstable.) Now we have a module A with a dependency on B-0.1.4 (and some more on C, D, ...). From pure anger I've defined the dependency on B as [0.1.4], which I always thought was a very strong way of expressing a version. When I build A, I would expect Maven to either give me a B-0.1.4 or COMPLAIN about it. Instead I'm getting an older version, say 0.0.6 (which does not fit the range I've defined oh-so near-by). When I look in dependency:tree, it shows me B as direct dependency of A (correct), with version 0.0.6 (supposedly incorrect) without giving any particulars like managed from. A is of the new regime, the others mixed. All versions of B are from the old regime. Why am I not the boss of my own dependency versions??? Thanks. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PLEASE TEST] Maven 2.1.0-M1-RC17
I've been testing RC17 as the external version for m2eclipse and its much much better than 2.0.9 or any of the other RC's. Its actually snappy. had some really weird things with plugin resolutions and stack overflows gioing on intermittently but they all look to be resolved. good work. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting Class Paths in the POM.XML
short answer is don't, define the dependencies that you need and let maven figure out the jars... http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html you may need to install the relevant jars into a local repository On Wed, 03 Sep 2008 11:57:17 Michael McGrady wrote: How do I configure the pom.xml to pickup jar files in the lib and devlib directories? Michael McGrady Senior Engineer Topia Technology, Inc. [EMAIL PROTECTED] 1 (253) 720-3365 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting Class Paths in the POM.XML
many of the felix jars are in the central repo which one are you missing? http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/felix/ On Wed, 03 Sep 2008 12:46:51 Michael McGrady wrote: I should have noted that the dependency I am interested in is not in the Maven repository. I am interested in using the Felix implementation of OSGi. Thanks, again. Mike On Sep 2, 2008, at 4:57 PM, Michael McGrady wrote: How do I configure the pom.xml to pickup jar files in the lib and devlib directories? Michael McGrady Senior Engineer Topia Technology, Inc. [EMAIL PROTECTED] 1 (253) 720-3365 Michael McGrady Senior Engineer Topia Technology, Inc. [EMAIL PROTECTED] 1 (253) 720-3365 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to cope with conflicting jar versions
thirdly version ranges give you deterministic and manageable conflicts. however in the case of spring you should not be mixing the different major revisions that will just give you headaches... use one or the other 1.2.X not compatible with 2.0.X not compatible with 2.5.X, i use version ranges to ensure that no projects cross pollinate... if they do one has to go up or the other down to get a deterministic result. On Tue, 26 Aug 2008 16:06:51 Geoffrey Wiseman wrote: On Mon, Aug 25, 2008 at 3:40 PM, Farrukh Najmi [EMAIL PROTECTED] wrote: In my project there are many direct and indirect dependencies at the lowest level on springframework jars. One such dependency requires use of the most recent springframework jars. Migrating to latest version of spring is my projects direct dependency causes problems at runtime with other dependencies which expect older versions of apis from spring and its dependencies. Is there a good way to deal with this dependency hell? If so I would appreciate any advice. Thanks. Generally, if a project closer to the root pom (fewer number of transitive dependencies away) calls for a version of the same dependency (same group id, artifact id) as a dependency farther away (greater number of transitive dependency hops), the former will be used to the exclusion of the latter, as I understand it. I find this solves the vast majority of the problems right there. A secondary mechanism is dependency management, where you can lock in versions of dependencies using the POM. I find this primarily useful at not requiring versions to be specified in sub-projects with a master POM. Finally, when you have issues where an artifact has been moved/renamed you may need to get into exclusions. - Geoffrey -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Eclipse Project
On Fri, 22 Aug 2008 08:28:36 Andrew Close wrote: On Thu, Aug 21, 2008 at 9:51 AM, Lam Hayward [EMAIL PROTECTED] wrote: Hi there, I have an issue with maven classpath generation (mvn eclipse:eclipse) for eclipse. I have 3 independent projects (say A, B and C) with no common root. Project A is the common project (jar) which project B and C will include. In pom.xml in project B and project C, there is a dependency defined for A. However, in eclipse, I'd like to have project B and project C to include the project A as reference project instead of the jar. Is this possible without using the project hierarchy approach? maybe you want to look into this: http://code.google.com/p/mvnlink/ it sounds like it does what you're looking for. use the m2eclipse.codehaus.org plugin and then run mvn eclipse:m2eclipse far better solution... there is one caveat make sure that maven and eclipse have different output folders... eclipse generates class are not meant to be packaged up... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-digester version conflicts
It unfortunately happens when there is a conflict as well... so if you have two ranges that cannot be resolved you get an OverConstrainedException which gets hidden with -X do mvn -X and you will see the exception... and can traceback to the conflict On Wed, 20 Aug 2008 03:18:38 Alex. wrote: This happen when Maven don't know whitch artifact version to use. [INFO] Failed to resolve artifact. Couldn't find a version in [1.6] to match range [1.7,) commons-digester:commons-digester:jar:null -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source and byte code in one single jar file
On Fri, 15 Aug 2008 11:02:41 Kalle Korhonen wrote: Haven't tried but if you just claim the java dir as a custom resource directory as well, what happens? I.e.: resources resource directorysrc/main/java/directory /resource /resources Kalle On Thu, Aug 14, 2008 at 3:38 PM, Mads Pultz [EMAIL PROTECTED] wrote: I would like to attach .java files to the jar file produced by the jar plugin. Is this possible and if so how? I know that I can produce a separate source jar file, but I would like to produce one single jar file consisting of both .class files and .java files. /Mads watch out for a feature/bug that means the source in that jar will be compiled when ever its included in a compile scope... i never figured out whether it was javac or the compiler plugin... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Snapshot parent
On Thu, 31 Jul 2008 09:44:41 sverhagen wrote: In Continuous Integration spirit, we have snapshot dependencies between all our own components. We have also set components to use snapshots of their parents (parent ... version...-SNAPSHOT). Is the latter good practice? It will mean that I can't release a component without releasing its parents, won't it? All your help would be appreciated -- this is really twisting my brain. you can achieve the same result using version ranges... i would not recommend snapshot parents... consider that continuous integration is there to verify that your artifacts are consistent and have valid inter artifact assumptions... if you use snapshots how do you really know whats broken and what fixes it you would be better off having a staging repository and a final release repository using the release plugin to manage the lifecycle rather than snapshots gives you far greater control -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versions of plugins used ...
On Thu, 24 Jul 2008 07:15:48 Thomas Darbois wrote: The best way to avoid that problem is to use a parent pom that define pluginmanagement so that each plugin used is clearly defined for your modules. Thats not necessarily the best way! Its one way. Does the new pom import dependency apply to plugin management as well, if so that might be more appropriate. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versions of plugins used ...
On Thu, 24 Jul 2008 07:31:47 Michael McCallum wrote: On Thu, 24 Jul 2008 07:15:48 Thomas Darbois wrote: The best way to avoid that problem is to use a parent pom that define The problem with parent poms is that they are versioned resources but people make use of the 'ignore the version just use the ../../pom.xml' parent with modules and inheritance. You end up using the parent on trunk/head. As a result you have no consistency. if you release your entire source tree each time then you ensure consistency but you lose all of the power of having prebuilt artifacts esp for larger teams. One key factor that people seem to forget is that when you composite dependencies each of those dependencies can have a different inheritance hierachy... for a very simple contrived example... parent 1 and 2 and 3 are released over time a :: parent 3 - b - d b :: parent 2 - e - c c :: parent 1 d :: parent 2 e :: parent 2 now if you resolve your dependencies for 'a' you get a (parent 3) - b (parent 2) - e (parent 2) - c (parent 1) - d (parent 2) if order for b, e, c and d to be consistent you have to honour their inheritance... i'll leave all the implications to the unfortunate reader ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Versions of plugins used ...
yes don't use modules... just release each artifact independently... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi Inheritance
You can easily solve that with composition rather than inheritance. e.g. domain.db.composite - db.driver domain.axis.composite - axis - spring ws and now... domain.web.project - domain.db.composite - domain.axis.composite each of the above can have a common parent that defines the distribution rules for you company... all repsitories can be specified in settings.xml On Tue, 22 Jul 2008 03:42:14 Raffaele wrote: Hi all, I have the following short question: should be possibile define a pom with two or more parent pom? A practical utilization: It would be useful having a pom which specifies db specific dependencies and a pom which specifies web specific dependencies, and my app could be child of both those pom(s). Thanks in advance, best regards Raffaele -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Maven support dependency group?
On Wed, 23 Jul 2008 14:51:00 youhaodeyi wrote: I want to make some dependencies into one group and let user dependent on this group. All the dependencies under this group will be added to maven project. Can I do this in Maven? yes just set the packaging to pom... and release as per a normal project... if you depend on it you will get all the transistions... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release plugin duplication
On Tue, 15 Jul 2008 07:05:52 Kallin Nagelberg wrote: thats hilarious did anyone else get three copies of that email ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross project refactoring in Eclipse with maven integration
using m2eclipse you can install the snapshots and refresh deps... the plugin will link the projects... you know because the dep shows a folder instead of a jar On Wed, 09 Jul 2008 03:35:44 Smith, Stephen R wrote: Now that I have maven handling my dependencies, how do I do cross Eclipse project refactoring or references or declarations. When my projects were linked, I could refactor a method in one project and dependent projects would be modified as well. It seems that once the project dependencies in the build path are converted into Maven dependencies, workspace wide searching and refactoring is broken. Stephen Smith -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 18:11:39 Peter Horlock wrote: Okay, one last thing - this conversation has helped me a LOT already, but, to catch it all, I need some more: 1) You say your version ranges wouldn't break a build - but what about ... sometimes even in the most obscure and hidden places, hard to find - same thing could happen with new dependency versions, couldn't it? I am therefore not yet totally convinced of transitive dependencies - it hides things, and then when you don't expect it, it might fail in a productive environment, if a test didn't catch it before. Nope you release the same artifact into dev, staging, and production... once you release a war then its made ( i also use the generate release pom flag for the release plugin but only for war/ear/assembly projects 2) When you are talking about composition, I know finally understood you are talking about using poms as a container to combine dependencies. But how soon will you start making such a combine pom? If you got 2 similar jars? 10? 20? What's the best ratio from your expierence? use standard refactoring techniques to evolve them... i tend to not usea number like that but rather compose again by implementation e.g. web service, logging, xml, jaxb, axis 3) Will those composition poms not clutter your project structure even more? ... already grumping about having to maintain the parent pom AND their project pom - I mean it has all its nice vantages, but on the other hand, it increases the projects complexity, in some way, too, you have to admit, don't you?! it does yes, but then mvn dependency:tree makes it all very clear... my ratio is 1:10 at the moment composition to real artifacts 4) I don't yet completly get the vantage of having all those seperate jars ... Do you get my point? It's hard to explain, I hope you get my analogy. A colleague pointed this out to me, and I didn't know how to answer it - imho it is a valid argument, isn't it??? this in an integration problem that always has to be addressed and it is solved by 1 communicaiton 2 process 3 continuous integration The ultimate goal it to manage the deliverable and write code. So if it did happen to break you can filter at an appropriate level of the resolution tree by either making a stricter range e.g. [1,2-!) to [1.5,1.19-!) So the point is things break, deal with it... don't make process so hard that you stiffle your ability to work. Last but not least - we have about 10 sub projects, but in one of those sub projects, there are between 1-4 people working. So you still got the problem if you break something in a sub project, you will influence up to 3 other developers I reckon your projects are too big... make them smaller. It means your units tests get more specific and its way easier to refactor adjust and often avoids the need to branch and merge. Please, bring some light in my confusion! :-) i think there is very little left now, I am quite delighted -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Sat, 05 Jul 2008 08:21:49 Jörg Schaible wrote: How do you address this QA problem? I cheat and use generated poms that write deps if i'm going to patch... or i make a new release with the latest and greatest... in both cases I go though a review to ensure that only the change we want makes into into production... so really its a manuall qa process... i could automate with scripts or a plugin to compare release pom vs resolved tree we release often so don't normally have a problem with latest and greatest -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 18:37:14 [EMAIL PROTECTED] wrote: The only time (admitedely) I use this is for a multi module J2EE project, where each module (WAR, EAR, EJB, JAR etc) all have the multi module pom as their parent, and the multi module pom has the corporate one as it's parent. I was told to do this, and in fact, if you you use archetype:create-from-project (?) that is how it generates the pom structure of the generated archetype. So, I'm curious as to why you would say not to do this. firstly there is this magic default relationship between a project and its parent esp if you put the parent in the parent directory... which means that end not having a consistent pom... it can inherit from the one on disk not the one specified... this might no longer be a problem but I had all sorts or problems and the user list it littered with them going back a long time and it just smells bad... it seems like with people are doing all sorts of nasty things to make the two work together... property interpolation.. snapshots... and you really don't need it... we just use release dependencies os there is no need to release a bunch of things in one go... i do use modules to generate docs and continuous integration but they are isolated and only aggregate for that purpose... i might be tempted to release more that one thing at a time with an aggregation but it has too many shortcuts based ont he bad smell of inheritance + aggregation gotta sleep more later -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filtering of a SINGLE property
Well maybe,
Why do you want the version in the code itself?
runtime resolution
-
Would it be sufficent (or perhaps better) to get it at runtime rather than
having it compiled in?
The maven jar plugin writes a file called pom.properties in
META-INF/maven/groupid/artifactid/pom.properties
this contains the version
I used to do all sorts of replacements in the far distant past when using ant.
Since moving to maven I have not really found many scenarios where that was
the best option.
other options
-
i can't see any being able to specify the tokens used for identifying
variables to replace or being able to disable the standard filters seem like
great ides... i would be pretty easy to patch the resources plugin for this.
On Sun, 06 Jul 2008 02:21:28 Peter Horlock wrote:
Noone?
Please, there must be someone able to answer this?!
Thanks,
Peter
2008/7/3 Peter Horlock [EMAIL PROTECTED]:
Hi,
I want to let Maven / the Resource plugin (
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-e
xclude.html )
parse my source code to replace {project.version} with the current
version of the project as defined in the pom.
This works great, but - in JSTL, as well as in OpenLazlo, ${variableName}
is also a variable of the language itself -
therefore, this leads to collisions - for example, one of our developers
used a variable named ${parent} which then was filtered by Maven and
booom the code was broken. Yada yada YAda!
= Is there a way of telling Maven to JUST filter certain properties? I
know I could tell it to just filter certain files,
but
a) a developer could then STILL use ${parent} as a variable in this very
file
b) whenever I wanted a new file to be filtered, I would have to add this
file to the filter section...
Thanks a lot folks,
Peter
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
from 3.2.5ga with one or two releases and then rebuilding the deliverables... unless of course 3.2.6ga breaks things in which case i might increment the major version of the composition... and upgrade one resolution tree at a time use the m2eclipse plugin so that deps work properly (or equivalent plugin for other ide of choice) Yeah, m2eclipse plugin's nice, however, it doesn't support Eclipse 3.4 yet! you should downgrade eclipse or patch the plugin... one key things is that when developing lots of disparate artifacts you can install the snapshot for each and the plugin will magically associate them in eclipse... that way you can have refactorings apply across all your projects at once one major GOTCHA to eclipse is that it merges the different scopes i.e. test and compile are indistiguishable, just means you should double check things on the command line... one other major GOTCHA is that eclipse and some plugin combinations on windows will lock your pom when you try to release and break the release half way through. The pain of exclusive read locks! :-( : regularly refactor at the artifact level not just code level Can you explain that in more detail? Yes you can do what i call artifactoring which bears some parallels to enterprise patterns. I am doing a presentation at the Auckland JUG in august and will post details here soon. Simple enough? 1. Use one and the same parent pom with snapshot as version nummer, or have different versions of the parent pom? I guess from what you wrote, different versions different versions, people get too hung up on artifact version but ultimately only the deliverable versions have meaning outside the dev team, just like revision numbers in source control don't matter as long as the pattern is consistent and decipherable. Ranges let you be really specific about what any project means. Using the hit and hope version def basically means you project can end up looking like anything. 2. Subprojects - version number directly in the project pom itself, or is it a good idea to have a property value for each sub project version in the parent pom, and so to keep the version in dependency management in sync with the most recent version of each current sub project version. I would keep it simple. My motto is each artifact should build in isolation when checked out. Property interpolation from parents causes all sorts of issues. So I always have a version in an artifact, the version for the artifact is for the artifact and not for any group of projects. If you try to enforce an arbitraty version lifecycle on many artifacts in a group where do you stop? do you just have one version? I think each artifact is better served with its own... it has its own deps, its own docs, its own tests it should have its own version. This also means projects all start looking the same. my standard layout is x y z modules - which includes x, y and z as modules for testing and documentation I find with granular artifacts that the interative churn is isolated into a few artifacts at a time. Over time you can isolate the unstable artifacts, these tend to end up with large major versions ;-) Often splitting them in two reduces the churn. Thanks a lot, Welcome -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses cglib... excludes commons-logging, excludes ehcache, excludes cglib-full and all my projects the use hibernate use hibernate.composite.[7,8-!) We make these adjustments directly in the depMgmnt of the global POM. which means you have to release from the top down. I can release any artifact any time... i live on the ready to release to production rather than beginning of build cycle line. Subtle but fundamental difference. And the overhead is minimal. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: 12) set up parents that define plugins for particular types of projects i.e. webapps, jars, parents, We setup the common settings in the pluginMgmnt of the global POM ... and lock down the plugin versions. not quite what i was getting at, my point was that plugin configurations tend to be common across function not group a common anti pattern in poms is to have company.pom - group.pom - model - service - war http://www.codinghorror.com/blog/archives/000589.html now repeat that pattern for 9 deliverables and you get Duplicated Code the plugin configuration either goes into company.pom Large Class or you have to refactor the inheritance to work by function company.parent - jar.parent - model.parent group/ model :: model.parent service :: service.parent You wil note things like this... cobertura branch/coverage constraints are different for services and models. The overhead of putting things in the company pom is that you need to change all the projects to the new version OR you can use snapshots and make it a major overhead to start a release cycle -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: 6) start version numbering 1.1 for new artifacts * makes ranges work better * who needs the extra .0 on the end, i save that for patches Why's that? Also remember that version 1 is implicitly 1.0.0.0 so that range [1,2-!) does includes 1.1-SNAPSHOT if i happen to install as a snapshot which is pretty common for a 1.1 version of an artifacts Because there is no need to label things 1.0.0. ... 1.0 is sufficient. When looking at any of the deliverables I produce you can tell immediately if it was a release or a patch by seeing 1.X, 2.X where as a patch would be 1.3.1. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: project.deployable uses implementation.[1,2-!) and consumer.[1,2-!) obviously in the real world things aren't this simple and for simple cases this seems like excessive overhead We do not use ranges at all. Works great without. Define great... You have no real definition of a build... its transient as saying i would like something that kinda resembles 3.4.5 of an artifacts does not really mean much at the end of the day. It would be possible for maven to resolve 2.0.5. (just look at our xml apis/xerces versions in dependency:tree) where as saying i can only use any 1.X version of an artifact is a lot more constraining. I would never get a deliverable which had version 3, or 2 etc. For the same reason that static type checking is good so are ranges. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: 8) use mvn dependency:resolve and mvn depedendency:tree regularly to understand how things are working and to catch any transitions that i did not expect Especially after upgrading version of 3rd party artifacts ;-) Actually that is _never_ a problem for me because I compose 3rd party artifacts into a separate pom thats the only place the deps can go wrong. When i upgrade the 3p library I isolate and control the depedencies in the composition. I can therefore guarantee that the dependency tree is no different than before or I can bump the major version to identify that the contract (i.e. same dep tree) is broken. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: 8) use mvn dependency:resolve and mvn depedendency:tree regularly to understand how things are working and to catch any transitions that i did not expect Especially after upgrading version of 3rd party artifacts ;-) Actually that is _never_ a problem for me because I compose 3rd party artifacts into a separate pom thats the only place the deps can go wrong. When i upgrade the 3p library I isolate and control the depedencies in the composition. I can therefore guarantee that the dependency tree is no different than before or I can bump the major version to identify that the contract (i.e. same dep tree) is broken. -- Michael McCallum Development Lead Ferrit Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.ferrit.co.nz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 02:29:07 Jörg Schaible wrote: I can release any artifact any time... i live on the ready to release to production rather than beginning of build cycle line. Subtle but fundamental difference. And the overhead is minimal. The overhead is that you produce a lot of versions that may live for just a view ours and that will not be of any use later. for you the lifecycle is 3 snapshot deploys... what if the last one breaks you code? depedending on the changeset it may be difficult to trace the path back through the changes even with source control... my way you may have extra version that are of no use unless you need to diagnose a problem with a change. Murphys law you don't need it until you do. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 10:08:44 Peter Horlock wrote: As I asked you before - when using version ranges, how can you ensure an upcoming 2.4 dependency will not break your build that was working with 2.3 ?! there are a few ways but mostly its development process 0) communication 0) planning 1) run an CI server that runs cycles of every trunk and against every trunk 2) use the reactor to run all the tests before you release 2.4 3) make when the distance between projects is not too large you should problably be using refactoring tools to make changes that break apis and it will apply to the depedent project too 4) use a staging repository for CI before promotion to the release repository There is another factor to consider though... breaking is only significant if its difficult to fix... with version ranges it is easy to remove the bad version from the resolution tree for all projects that may be affected and then beer fine those responsible ;-) there will never be a tool that stops developers making mistakes, there are tools to help developers mitigate the cost of those mistakes, thank you maven. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 02:52:09 Peter Horlock wrote: The problem I see with version ranges, is you start loosing control. Not true it means you have complete control. Unless you use [1.5] in all your versions you are asking maven to make a best effort to give you 1.5. I guess the vital part to make the use of version ranges work (at all) is that every developer has to follow the rule No version ranges work fine in most cases, however I find that its best to keep it simple. You only and always change the minor version when you release an artifact unless you have branched and then you increment the patch number. The major version is a discussion with the team to say we are adding this new feature and need to make this change that will break the previous contract of the artifact. major.minor.patch... So far, we have been very loose with versions - Someone changes 5 lines in the code, makes a new (patch) version, someone else changes another 7 lines, makes another (patch) version, and so on - we keep on patching the jar - 1.3.57 - I wonder when we will hit a hundred or a thousand! ;-) versions have nothing to do with how much or how little has changed. It usually depends on the artifact. Some are volatile and other not. The non volatile ones tend to get reused all over the place. the only time we have had broken builds was when someone made a change that broke the contract and had not discussed it. its easy enough to adjust a range if you have to e.g. [2,2.4-!) I think i might be possible to So I guess if EVERY developer would only use the patch section if it was really just a minor patch that will not influence anything really, but would use the minor or major section for all other changes, ranges might work without breaking other ppls builds - but this mechanismus counts on this very ability, which is hard to maintain, especially with new developers joining the team. When you have strict versions everyone has to change to a new version deliberately. I specifically set things up this was to cope with new developers, they can pick up one artifact it just works, they can build ti and release it. You can get them started and ease them into how things work. About the thing with version numbers as property values in the parent pom - I am still not sure this is the best way, especially not with project that are not really shared by others, Its a bad idea all around. it makes maintenance and nightmare and plugins and other things don't always interpolate those properties correctly, and you end up with the version being that of some obscure plugin... very annoying. but this is the easiest way to update the dependency management section - otherwise, when someone changes the version of a submodule, one has to change this version, as well as the version in dep. mgmt. see previous post on sticking depMg in another common project with a pom dependency ... i dont do it this way but use a similar approach with factored dependencies H, this is really hard to swallow, I can't really find THE one and only solution of how to solve this dilemma - well, maybe I am still missing something? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 03:59:29 Peter Horlock wrote: Sorry, but what's the purpose of the release plugin anyway? It's site doesn't really tell it: http://maven.apache.org/plugins/maven-release-plugin/ Very good question and simple to answer... release-prepare - the release plugin will build and test your project then tag it. release-perform -check out the code from the tag and build the artifact and test it and then deploy it essentially a maven repository is just a cache of prebuilt tags, you can always rebuild an artifact by providing the tag path to release-perform once you are in the habit of releasing and set up some aliases or batch files its painless, -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 02:43:03 Jörg Schaible wrote: Sorry, but our priority is to ensure that all artifacts are built with the same plugins and use the same artifact versions. In your model I have to duplicate all the versions for your individual service parents. That's what I call an anti-pattern. No, thanks, we've already bitten enough by that. I do specific plugin versions strictly and dependency versions strictly too. Its just the one is by composition and one by inheritance. Consider this thought experiment: 1) push all your configuration down to the leaf poms 2) there will be tonnes of duplication 3) now look at the patterns of duplication 4) you can use standard factoring techniques to take common sets of dependencies and put them into a composition (a pom which just collects other dependencies) (its even possible to put dependency management in here. 5) once you have factored out all the common dependencies you will see the the remaining patterns of configuration fall into functional groups... one for jars, one for wars, one for ears, one for jaxb2 projects etc etc (one could be n). So step 5 says to pull up that configuration into common parents by fucntion not by group. I guarantee that if you do this your poms will halve in size One of the _really_ important features of using composition whether or not you use depMgt is that you can (with version ranges) make a change that remains consistent across all your projects To prove this consider A extends P-1 and B extends P-2. P-2 changes the version of commons collections however C depends on A and B which version do I end up with in C? It either depends on the order of resolution of A and B OR i can add commons collections to C as well. It becomes really unwieldy. You need to factor and isolate, I'm sure it makes perfect sense. Maybe I'm missing something but I've been doing this for several years and it works. All kind of individual plugin configuration tend to be really individual. As long as Maven does not support to reuse certain POM sections (like it is now available with scope import at least for the depMgmnt), you will not be able to avoid some duplication in the POMs. the plugin configurations are merged so you can override specific properties in the child with the 'abstract' configuration resolve from the parent hierachy The overhead of putting things in the company pom is that you need to change all the projects to the new version OR you can use snapshots and make it a major overhead to start a release cycle It depends on your development model. We do the second and it works well. it does and thats fair enough. But I worked on another project where they did the same thing and said it worked well. But people still wasted half days all the time when someone snapshot'd something that broke everything else accidentally and there was no simple path backward. You might as well go back to one big source tree... Please take all comments with a large grain of salt. Not intending to offend anyone, ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 02:59:10 Peter Horlock wrote: 2008/7/3 Jörg Schaible [EMAIL PROTECTED]: Sorry, but our priority is to ensure that all artifacts are built with the same plugins and use the same artifact versions. In your model I have to duplicate all the versions for your individual service parents. That's what I call an anti-pattern. No, thanks, we've already bitten enough by that. I am not sure if I properly got your point, but I also think that using version ranges and no proper dep. mgmt will lead to using different submodule version in the same project. We had that with Maven 1, and wasn't no you factor out the dependency and its enforced as consistent but still manageable. with the composition of depMgt with the new pom import support you can do what i'm saying with depMagt and not using inheritance -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Fri, 04 Jul 2008 10:01:43 Peter Horlock wrote: Hm, but for such analysis, isn't that what subversion is for?! sure but where to look, if you built a snapshot what revision am i looking for. If you have tags then you can easily see changes between checkpoints -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lock down of plugin versions
i don't think plugin resolution supports ranges, the brackets are implied for plugins in that they are all strict versions. i've have go back and read the code again... On Fri, 04 Jul 2008 03:12:35 André Kelpe wrote: Hi Jan! I'm running Maven 2.0.9 on Windows JDK 1.5 through Cygwin. We have set up Proximity as a corporate proxy and I have followed the guide in the Sonatype book to configure repositories and mirrors in my settings. Adding this block to my POM: pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-clean-plugin/artifactId version[2.2]/version /plugin /plugins /pluginManagement Removing the brackets from the version, if you do not use ranges should do the trick. HTH André - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
On Thu, 03 Jul 2008 00:44:20 Peter Horlock wrote: Could you be a bit more precise? (Just make it plain simple, this increases the chance that I get it! ;-) I suppose The things i do 1) parent version are always release versions 2) all depedencies are always release versions 3) release often 4) use version ranges to manage the contracts e.g. project.api = 1.x project.implementation uses api.[1,2-!) project.consumer uses api.[1,2-!) project.deployable uses implementation.[1,2-!) and consumer.[1,2-!) obviously in the real world things aren't this simple and for simple cases this seems like excessive overhead 5) when ever you make a breaking change increment the major version 6) start version numbering 1.1 for new artifacts * makes ranges work better * who needs the extra .0 on the end, i save that for patches 7) in order to integrate 3p libraries i create a wrapping pom which follows the above version rules e.g. for hibernate i have hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses cglib... excludes commons-logging, excludes ehcache, excludes cglib-full and all my projects the use hibernate use hibernate.composite.[7,8-!) 8) use mvn dependency:resolve and mvn depedendency:tree regularly to understand how things are working and to catch any transitions that i did not expect 9) set up aliases alias mvnsrc='mvn dependency:sources' alias mvntag='mvn release:prepare -Penforce-no-snapshots' alias mvntree='mvn dependency:tree' alias mvnup='mvn release:perform -Dgoals=deploy' alias mvndep='mvn dependency:resolve' 10) use the enforcer to ensure releases don't contain snapshots make sure to traverse transitions 11) don't mix inheritance and aggregation. that means a parent pom NEVER ever has modules, if you think about the concept for a minute - or longer - there will be a moment of enlightenment 12) set up parents that define plugins for particular types of projects i.e. webapps, jars, parents, 13) define repositories in settings.xml, been meaning patch the settings resolver to load profiles from a directory so that i can source control the repositories for different projects independency 14) keep all artifacts granular to simplify resolution trees and isolate change 15) use the m2eclipse plugin so that deps work properly (or equivalent plugin for other ide of choice) 16) DONT use the same output folders for eclipse and for maven as eclipse instruments classes and it will break things 17) regularly refactor at the artifact level not just code level Simple enough? I might diverge from common practise in some places but I'm pretty sure from watching the lists that I have way fewer problems as a result ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
Think about poms and dependendencies in the same way you would a piece of OO code. You should use inheritance, composition and aggregation appropriately to reduce change and improve stability. Don't make the mistake of thinking that inheritance is the only solution. On Tue, 01 Jul 2008 23:39:51 Peter Horlock wrote: Hi, we got a software, which is devided into serveral sub projects. We defined a parent pom, that, besides other shared items, contains a dependency management section to ensure all sub projects are using the same dependencies. Also, as the software we are talking about is actually a website, there is never really something like a final version or so - the product is constantly under development (with a monthly release cyclus). Based on these preconditions, I figured out the following handling: So far, we have the parent pom always as a SNAPSHOT version, and did not differ between different versions of the parent pom. So far, we have all dependencies - external as well as internal depdencies (the sub projects themself) under dependency management. When someone wants to change the version of a specific sub project, he does so by editing a property in the parent pom mysubprojectXY-version1.11/mysubprojectXY-version which, on the basis of this property, will then change the version in depdency management, as well as the version of the sub project itself (and so keep them in sync). This ensures all subprojects are ALWAYS using exactly the same dependencies - external ones from other suppliers, as well as internal ones provides by ourself. However, the problem now is that when someone changes something in some sub project, he could hardly ensure this change will not conflict with a certain other sub project that might also use this project (and as so far we only have one version of the parent pom, all projects will always get the latest version of the parent pom, and so will also always get all updates from all sub projects...) 1. Therefore, I suppose it was better if we were using different parent pom versions, right? In otherwords, if someone wants to change the version of a sub project, he would also have to change the version of the parent pom, there he would increment the version of the parent pom, as well as the version of the sub project. When someone else wants to use the new paret pom, he would deliberately change the parent pom he is using, and so he would know that he had to check for version changes and their influences on his specific sub project. 2. What about the version numbers of the sub projects? a) Is it a good idea to have them entirely managed in the parent pom (by using a property, which is used in dependency management section, as well as in the sub project version itself?), or b) Is it a better idea to hard code the version of a sub project in its pom? Based on the strength of past experience, I suppose it was best to use different parent pom version for every release, and in between to maybe use snapshot version, plus to keep up the process of having internal as well as external dependencies in dep. management, and to keep the version in dep. management with the last version of a certain sub project in sync by using properties. Do you agree? Or do you suggest another approach? Thanks in advance, Peter -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tip about Skinny Wars
On Tue, Jul 1, 2008 at 2:58 PM, Martin Höller [EMAIL PROTECTED] wrote: I think I found one BIG problem with your workaround: it only works if you already have (the latest version of) your WAR's pom.xml file in the repository, otherwise maven 2.0.9 reports a missing dependency. So this approach is not useable with the maven-release-plugin :-( Rubbish i use this all the time with 2.0.9 without any problems. Have been since 2.0.5 and for at least for the last 6 months. It might be because I use ranges for deps though, and I don't use modules. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and organization of source tree in SCM toolset
branch by artifact when necessary but I have found that the use of ranges and api artifacts has almost completely removed the need for traditional branching. By defining the ranges in the deployables you get a consistent deliverable and can have parallel development and patching without necessarily. e.g. trunk/ /groupId.a /artifactid.a /artifactid.b /artifactid.c /reactor (just used for testing and occasionally installing the group) /groupId.b /artifactid.a /artifactid.b tags/ /groupId.a /artifactid.a /1.1 /1.2 /2.1 /2.2 /1.2.1 (tagged from branch) /artifactid.b /... /artifactid.c /... branches /groupId.a /artifactid.a /1.2 (when trunk goes to 2+ any changes go on 1.2 branch) The decision to increment the major version is for a breaking change. We use very granular artifacts where each artifact serves one function and the pom hierachy is by function not by module or group. This leads to significant reuse and most artifacts stabilise very quickly and don't need changing. Quick often also I have found that when it looks like a change in an artifact would require a branch to support two different deliverables that splitting the artifact in two allowed the change to be painlessly integrated into more than one deliverable with no delayed integration hassle. There are two things to consider as well what works with maven and what works in your ide (with maven support). I don't use modules or deployed snapshots because I have found eclipse support to be very unreliable with all sorts of indecipherable classpath issues. for ranges I use the [1,2-!) notation and start numbering from 1.1 so that 1.1-SNAPSHOT through to 1.n where n 2.0.0-SNAPSHOT match the range. If you start from 1-SNAPSHOT or 1.0.0-SNAPSHOT then a range of [1,2-!) wont match an installed snapshot which is probably why most people don't use ranges I suspect. The other gotcha is that [1,2) will match 2-SNAPSHOT and 2.0.0-SNAPSHOT as its 2.0.0. Another reason I suspect why people don't use ranges. There were a large number of bugs fixed since 2.0.4 in relation to ranges that have made them really work. One day i'll get around to putting something up on the net about how i've structured my projects and why. On Thu, 29 May 2008 21:42:14 Bracewell, Robert wrote: Hi, I am trying to get an understanding of how users are using the Maven toolset with SCM tools such as Perforce to handle branching strategies. Does anyone know of any such white papers or further reading or be willing to share current practices? Do users tend to use a dense hierarchical structure to store the structure of the project that Maven builds and as a result branch the whole tree when doing a release or use a flat component structure thus promoting re-use and only branch the module that changes when doing a release. From my experience to date with Maven I am finding that the Maven toolset is geared to the hierarchical structure and does not lend itself well to a flat component approach. Are other users running into such issues or have you overcome some issues? -- Robert -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and organization of source tree in SCM toolset
On Thu, 29 May 2008 23:52:35 Bracewell, Robert wrote: This is roughly what I seem to be moving towards. Over the past couple of days I have been converting a hierarchical project into an approach similar to what you listed to get a feel for things One key thing is that my pom hierachy looks like this... root - jar - service - api - model - jaxb2 - webapp - abstract webapp - assembly each of these parents contains the plugin configs needed for the particular artifact. Any given artifact would inherit from one of there functional parents. So a model project has standard jar plugins and very basic metrics and checks as its mostly just basic beans where as a service project would need to pass at least an 80/60 cobertura report for units tests. The groupId for me is related to the position in the source control hierarchy and maven reposititory but nothing else really. My biggest issue at the moment, although I have not tried to solve it is that I want the reactor to generate my docs and NOT use inheritance in any way for it just aggregation. I'm hoping thats what dashboard is for but time has not permitted research. I think I might need to figure out how to package up and deploy the xml report outputs so that any site aggregator can accumulate the site for a deliverable. As the site docs generally should accompany a released deliverable not the overall source tree, that always seemed backwards to me. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to better manage cascading releases
On Fri, 30 May 2008 03:42:09 [EMAIL PROTECTED] wrote: So there seems to be 3 possible conclusions: - There is any easy way to make these kinds of cascading releases, but we just don't know about it - There is a better way to structure our Maven projects so this doesn't happen in the first place (keeping in mind that we are happy with how the code itself is architected currently) - This is just the way it is, so we should get used to it Can anyone comment on this? release early release often... we don't use snapshot dependencies and release artifacts early. So if you are working on one of the 13 dependent libraries as soon as you - the dev - is happy the change is ready for use then you release it. why leave it as a snapshot? If the change would break anything useing it we bump the major version up so its not pulled in until downstream users are ready. if you use version ranges and manage codelines by major version then you can easily have the trunk of a project being actively developed and released without pulling it into a deliverable. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY] How does your team retrieve artifacts?
On Wed, 21 May 2008 18:15:44 Jason van Zyl wrote: [X] Our team uses HTTP to retrieve our artifacts This is the third team i've been in that uses http(s), I was using scp for a while but its was just waaay too difficult for windows users to get working. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify Classpath
On Wed, 14 May 2008 11:18:54 Wendy Smoak wrote: On Tue, May 13, 2008 at 11:23 AM, vicki [EMAIL PROTECTED] wrote: I have a maven's subproject that runs tests against the artifacts of its piers subprojects. Obviously, In other words, to run my tests I need to create dependencies on the artifacts produced by the other subprojects. I run my tests with maven's exec plugin. All the artifacts packaged as jars are indeed on my classpath when I run maven exec. But dependencies on the artifacts packaged as wars are not resolved in such a way that classes directory inside these wars are put on the classpath. Java simply has no concept of putting a war file on the classpath. If you have code in a war module that you need to use elsewhere, the best idea is to move the code to a separate module that builds a jar. That jar then becomes a dependency of your war module plus any other module that needs it. If you absolutely can't move the code, the next version of the war plugin will have the ability to deploy a classified/attached artifact containing the code from a war module. 1) you can make the packaging type of the project jar 2) add a config for the war plugin to execute war... plugin artifactIdmaven-war-plugin/artifactId version2.1-alpha-1/version executions execution goals goalwar/goal /goals /execution /executions configuration archiveClassestrue/archiveClasses classifierapplication/classifier /configuration /plugin 3) this gives you a jar and a war 4) you can then depend upon the jar (default) artifact to get the deps of this project and if you need to dependency groupIda.b/groupId artifactIda.b.c/artifactId version[1,2-!)/version /dependency 5) to use this war as an underlay you can depend on the project with classifier 'application' dependency groupIda.b/groupId artifactIda.b.c/artifactId version[1,2-!)/version typewar/type /dependency -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modify Classpath
in my particular case i needed the code for integration tests so was borderline as to whether the artifact was actually separate or not... but in general i would agree On Wed, 14 May 2008 12:02:13 Brian E. Fox wrote: If you have classes that you need outside a war, the correct way is to make this into a jar that is used externally and also packaged inside your war. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Tree with child-parent relationships
sorry just reread email you want reverse deps... not an easy problem to solve unless you are google... -- Michael McCallum Development Lead Ferrit Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.ferrit.co.nz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependency Tree with child-parent relationships
mvn dependency:tree (if it complains about plugin not existing try -U) On Tue, 06 May 2008 04:16:10 Baeriswyl Kuno - Extern (IT-BA-MV) wrote: Hello! I need to know if there exists a tool that resolves all child-parent relationships for Maven2. More precisely, I want to know which artefacts depend on a given artefact. Example: A - B, B - C and D - C For the example above, I want a tool that shows me A,B and D for the given artefact C. All the tools I've found, like dependency:tree Mojo or JFrog Dependeny Analyser, resolve the parent-child relationships only. I know that Archiva, a Maven Repository, does resolve the first degree of child-parent relationship, however, I don't want to introduce this tool just because of this nice feature. Further more, I'd like to have resolved the whole tree. Thanks for your input. Kuno -- Michael McCallum Development Lead Ferrit Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.ferrit.co.nz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote: Still, I don't like the way how I have to manually distribute the path to the current JDK into various config files. you have to anyway it just happens you set an environment variable which is a bit average at the best of times. Packaged OS's do most of the hard work for you e.g. Gentoo manages the JAVA_HOME, MAVEN_HOME during script invocation, I think debian based linuxes do as well -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice to represent an arbitrary collection of jars as a single dependency?
On Wed, 27 Feb 2008 07:41:16 Wayne Fay wrote: This simply is not a feature that currently exists in Maven, and for a lot of reasons, I don't see it being a feature that will be implemented any time soon. Your best bet is the list all artifacts as dependencies in a pom, and depend on it option that I suggested earlier. This in combination with Archiva, Artifactory, Proximity etc would be the right solution in my book. Is this the best bet or the one below? But, I don't think your projects actually need all 50 of those artifacts. So the best solution is to specify the proper dependencies explicitly in each project, and use a shared parent with a dependencyManagement section that helps you manage versions of artifacts. do you really find that this helps? consider this very contrived but representative of more complex scenerios example P == parent, A == artifact, W == webapp or other assembly P2 :: A1 P1 :: A2 P2 :: A3 P2 :: W1 A2 - A1 A3 - A2 W1 - A3, A2 If P2 is has a significant change in verssion how do you know that you have an inconsistent build when you build W1? If you use the right solution - as above - then you can actually get the ability with version ranges to have maven error when trying to build W1 if A2 and A3 are inconsistence in their resolution tree and potentially class incompatible. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared modules and versioning
for A and C i have...
dependencies
dependency
artifactIdB/artifactId
groupIdmy.company/groupId
version[1,2-!)/version
/dependency
/depedencies
if I release B such that I create an incompatible release then release B as
2.X
we don't use modules, or pom inheritance for dependency management...
and it works very well...
On Fri, 22 Feb 2008 02:38:30 EJ Ciramella wrote:
No no - if module A and module C depend on module B (which is developed
by your company), how do you NOT put different versions in module A and
C?
We've done things like created a property in the pom that's the parent
(the top most) of all the projects and in the sub projects, they all
reference this property via the ${some.version.name} type convention.
But, shortly, all these modules will be in their own branch and the
concept of a parent pom (the one to rule them all) will go away and
we'll lose this ability.
What we've talked about doing is module A and module C will have the
property and all their sub projects will reference that property via the
${foo.property} convention as described above. THEN - we'll have a pom
that has dependencies on all these various modules poms (they'll have to
be installed in our internal repository) and we can run the dependency
convergence/dependency:analyze plugins.
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 10:01 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
i use standard refactoring techniques to avoid duplication and ensure
clean
dependency trees
On Thu, 21 Feb 2008 14:56:19 EJ Ciramella wrote:
Hmmm - that seems like a lot of work/duplication. Why not set it in
some higher level pom as a property and then use ${} type syntax to
expand it at your lower poms? What if someone doesn't
fix/change/update
one of the poms version entries?
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 7:29 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
all the poms... although I would not recommend using version ranges
for
external libraries that you have no control over
i've worked around that by using dependency compositions
On Thu, 21 Feb 2008 12:03:53 EJ Ciramella wrote:
How do you implement version ranges? I think that could get us a
bit
further along, but still - where do you store this range of
versions?
Which pom?
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 5:19 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
by a process of review by the person responsible...
however you could use version ranges and have a project that depends
on
all
your deployable units. With appropriate version ranges you will get
overcontrained version exceptions when someone has made the
deployables
inconsistent.
On Thu, 21 Feb 2008 08:11:35 EJ Ciramella wrote:
So we have a module that is shared across multiple deployable
units.
It's imperative that each deployable unit uses the SAME version of
this
dependency.
If these deployable units are in their OWN project structure, how
do
you
uniformly enforce they use the same version without letting each
deployable unit have it's very own dependency listing. We've
tried
making the version a property in our current parent project, but
this
doesn't feel like it's the correct place to put them (we're slowly
becoming more and more modular - and realizing there's no true
parent
to
all projects).
How have people solved this in scenario?
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared modules and versioning
by a process of review by the person responsible... however you could use version ranges and have a project that depends on all your deployable units. With appropriate version ranges you will get overcontrained version exceptions when someone has made the deployables inconsistent. On Thu, 21 Feb 2008 08:11:35 EJ Ciramella wrote: So we have a module that is shared across multiple deployable units. It's imperative that each deployable unit uses the SAME version of this dependency. If these deployable units are in their OWN project structure, how do you uniformly enforce they use the same version without letting each deployable unit have it's very own dependency listing. We've tried making the version a property in our current parent project, but this doesn't feel like it's the correct place to put them (we're slowly becoming more and more modular - and realizing there's no true parent to all projects). How have people solved this in scenario? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared modules and versioning
all the poms... although I would not recommend using version ranges for external libraries that you have no control over i've worked around that by using dependency compositions On Thu, 21 Feb 2008 12:03:53 EJ Ciramella wrote: How do you implement version ranges? I think that could get us a bit further along, but still - where do you store this range of versions? Which pom? -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 20, 2008 5:19 PM To: Maven Users List Subject: Re: Shared modules and versioning by a process of review by the person responsible... however you could use version ranges and have a project that depends on all your deployable units. With appropriate version ranges you will get overcontrained version exceptions when someone has made the deployables inconsistent. On Thu, 21 Feb 2008 08:11:35 EJ Ciramella wrote: So we have a module that is shared across multiple deployable units. It's imperative that each deployable unit uses the SAME version of this dependency. If these deployable units are in their OWN project structure, how do you uniformly enforce they use the same version without letting each deployable unit have it's very own dependency listing. We've tried making the version a property in our current parent project, but this doesn't feel like it's the correct place to put them (we're slowly becoming more and more modular - and realizing there's no true parent to all projects). How have people solved this in scenario? -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shared modules and versioning
i use standard refactoring techniques to avoid duplication and ensure clean
dependency trees
On Thu, 21 Feb 2008 14:56:19 EJ Ciramella wrote:
Hmmm - that seems like a lot of work/duplication. Why not set it in
some higher level pom as a property and then use ${} type syntax to
expand it at your lower poms? What if someone doesn't fix/change/update
one of the poms version entries?
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 7:29 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
all the poms... although I would not recommend using version ranges for
external libraries that you have no control over
i've worked around that by using dependency compositions
On Thu, 21 Feb 2008 12:03:53 EJ Ciramella wrote:
How do you implement version ranges? I think that could get us a bit
further along, but still - where do you store this range of versions?
Which pom?
-Original Message-
From: Michael McCallum [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 20, 2008 5:19 PM
To: Maven Users List
Subject: Re: Shared modules and versioning
by a process of review by the person responsible...
however you could use version ranges and have a project that depends
on
all
your deployable units. With appropriate version ranges you will get
overcontrained version exceptions when someone has made the
deployables
inconsistent.
On Thu, 21 Feb 2008 08:11:35 EJ Ciramella wrote:
So we have a module that is shared across multiple deployable units.
It's imperative that each deployable unit uses the SAME version of
this
dependency.
If these deployable units are in their OWN project structure, how do
you
uniformly enforce they use the same version without letting each
deployable unit have it's very own dependency listing. We've tried
making the version a property in our current parent project, but
this
doesn't feel like it's the correct place to put them (we're slowly
becoming more and more modular - and realizing there's no true
parent
to
all projects).
How have people solved this in scenario?
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Good Project Structure for Web Services?
simple question for you so this structure looks 'nice'... what do you do when you have 2 webservices? 3? 4? now you have that in you head look at your poms... where is the duplication? in the configuration of the plugins in each of the so called children. if you have a parent of client and stub and service its not possible to factor that plugin configuration up... if however you had parents - distribution-management-parent aka company pom - client-parent :: distribution-management-parent - service-parent :: distribution-management-parent - stubs-parent :: distribution-management-parent ws1 - common-deps :: distribution-management-parent - client :: client-parent - service :: service-parent - stubs :: stubs-parent ws2 - common-deps :: distribution-management-parent - client :: client-parent - service :: service-parent - stubs :: stubs-parent ws(n) if you need common deps you can compose them in a common artifact of the client, service and stub siblings. the common deps may include the schema, wsdl etc as well (its unfortunate many plugins do not support loading resources from the classpath) if you still want a project aggregation you can will make ws1, ws2 as modules projects but that does not imply or require inheritance... On Wed, 20 Feb 2008 13:20:12 Mathieu Lemay wrote: Hello everyone, I'm struggling at getting a good structure for webservice packages. From the WSDL Java stubs will be created therefore should the structure be: parent -client -stubs -service where parent also contains the schemas and WSDL files as well as any server-config.wsdd , or other elements? Or should I find a way to have all three artifacts (client, stubs and service jars) be created from the parent pom (classifiers). I will also have to create a special pacakge (called GAR) from the three JARS + WSDL + config files and special deployment descriptors. I'm creating the plugin for creating GARs at the moment but I'm now wondering if this plugin should create the submodule when creating STUBS via the WSDL2Java. Help Please? Mathieu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Good Project Structure for Web Services?
my ws1 and ws2 were conceptual... i would have ws1 - client - services - gar the gar project would be a new packaging that created an assembly from the bits and pieces required e.g. (making things up but hopefully you get the idea) configuration wsdlclasspath:/com/company/ws1/wsdl/service.wsdl/wsdl configuration in regard to the stubs... not really sure perhaps bundle the wsdl in its own artifact and generate the stubs there with a custom plugin... or exec or something On Wed, 20 Feb 2008 14:26:01 Mathieu Lemay wrote: Thanks alot Michael, Indeed that makes quite alot of sense especially since we have 15 grid services that we want to migrate. I had thought of creating a single parent pom but that is probably more acurate as client deps are not the same as service/stubs deps. However since I'm writing the WSDL2Java mojo (it is not normal Axis) I was wondering if there is a way to programatically create the stubs subproject along with its pom file from goal in the ws1 package pom. I'll try to explain a little more: - parent (package .POM) -- service-parent (must have a .GAR package output) -- ws1 (must have a .GAR package output) --- client (output .JAR) --- services (output .JAR) --- stubs (output.JAR) -- ws2 (must have a .GAR package output) --- client (output .JAR) --- services (output .JAR) --- stubs (output.JAR) That's the last question (I hope) but can I put a bunch of stuff under the ws1/src/main/resources directory such as WSDL / deployment descriptor etc? And have my .GAR Mojo pacakge the JAR along with the differen config files / hibernate map files and client shell scripts? Thank you again! Mathieu - Original Message - From: Michael McCallum [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Tuesday, February 19, 2008 7:47:26 PM (GMT-0500) America/New_York Subject: Re: Good Project Structure for Web Services? simple question for you so this structure looks 'nice'... what do you do when you have 2 webservices? 3? 4? now you have that in you head look at your poms... where is the duplication? in the configuration of the plugins in each of the so called children. if you have a parent of client and stub and service its not possible to factor that plugin configuration up... if however you had parents - distribution-management-parent aka company pom - client-parent :: distribution-management-parent - service-parent :: distribution-management-parent - stubs-parent :: distribution-management-parent ws1 - common-deps :: distribution-management-parent - client :: client-parent - service :: service-parent - stubs :: stubs-parent ws2 - common-deps :: distribution-management-parent - client :: client-parent - service :: service-parent - stubs :: stubs-parent ws(n) if you need common deps you can compose them in a common artifact of the client, service and stub siblings. the common deps may include the schema, wsdl etc as well (its unfortunate many plugins do not support loading resources from the classpath) if you still want a project aggregation you can will make ws1, ws2 as modules projects but that does not imply or require inheritance... On Wed, 20 Feb 2008 13:20:12 Mathieu Lemay wrote: Hello everyone, I'm struggling at getting a good structure for webservice packages. From the WSDL Java stubs will be created therefore should the structure be: parent -client -stubs -service where parent also contains the schemas and WSDL files as well as any server-config.wsdd , or other elements? Or should I find a way to have all three artifacts (client, stubs and service jars) be created from the parent pom (classifiers). I will also have to create a special pacakge (called GAR) from the three JARS + WSDL + config files and special deployment descriptors. I'm creating the plugin for creating GARs at the moment but I'm now wondering if this plugin should create the submodule when creating STUBS via the WSDL2Java. Help Please? Mathieu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How can I disable maven download source-code and javadoc for dependency jars?
mvn dependency:resolve and mvn dependency:sources On Wed, 20 Feb 2008 13:51:44 youhaodeyi wrote: Hi, Dennis I know what wrong. I work with eclipse and the setting of eclipse is to download source code and java doc. Now I disabled it in eclipse. I just wander how to enable download source code and java-doc in mvn command. Dennis Lundberg-2 wrote: youhaodeyi wrote: My maven will try to download all the dependency jars including source-code and javadoc. There are many errors for downloading source-code and javadoc. How can disable maven to download them? What command are you using when this happens? To the best of my knowledge, downloading of -source and -javadoc jars are *off* by default. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to debug transitive dependencies
On Tue, 05 Feb 2008 10:03:56 Arash Bizhan zadeh wrote: I am getting some strange unrelated jar files inside my war package. Could somebody tell me how can I debug the transitive resolution process and eliminate unrelated jar files? Thanks Arash mvn dependency:resolve -X -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to debug transitive dependencies
make sure you 'mvn clean' after you remove the deps otherwise they are still sitting in the exploded war in target... On Tue, 05 Feb 2008 15:40:45 Arash Bizhan zadeh wrote: I got the problem. Strangely myfaces and portlet APIs were ended up in my war file. The problem was that I mentioned commons-chaining in pom as a dependency, and it is depend on those jar files; I removed the explicit dependency to it and strangely, now I have it in my war file but not the dependencies to myfaces and ...! Though I could not completely figure out how transitive dependency works and why this happened?! On Feb 4, 2008 6:19 PM, Martin Gainty [EMAIL PROTECTED] wrote: try mvn -npu -npu,--no-plugin-updates Suppress upToDate check for any relevant registered plugins which jars are being included that are not supposed to be included? M- - Original Message - From: Michael McCallum [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Monday, February 04, 2008 6:11 PM Subject: Re: How to debug transitive dependencies On Tue, 05 Feb 2008 10:03:56 Arash Bizhan zadeh wrote: I am getting some strange unrelated jar files inside my war package. Could somebody tell me how can I debug the transitive resolution process and eliminate unrelated jar files? Thanks mvn dependency:resolve -X -- Michael McCallum Enterprise Engineer mailto:[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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: organizing groups of dependencies
You can specify a pom dependency in any project just as you would any other dependency and the transitions take care of the rest... using standard OO prinicples you can encapsulate a common set of deps in a another project and depend on it from many, there is no need for the dependency management section one might even argue that makes it way more complicated that is necessary On Mon, 28 Jan 2008 20:07:36 Rohnny Moland wrote: Hei, I am trying to figure out the best way to group dependencies for easier maintainance. I was reading this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg61076.html Which is close to what I am looking for. Is this something that is going to be implemented in a later maven version? I also know that today it is possible to do what is described here: http://jira.codehaus.org/browse/MNG-2059 This is a nice solution if you have 1 dependency group, but not so nice if you have 3, because one pom can only inherit from one another pom. Lets say: parent pom ^ test-deps pom ^ gui-deps pom ^ product A ^ jar module 1 jar module 2 .. Any other ways to do this? Would be nice if maven had multiple inheritance. Thanks, Rohnny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven 2 war packaging - adds unwanted jars in WEB-INF/lib
use mvn dependency:resolve to see the list of dependencies and their scopes... you can add -X to see the resolution process On Fri, 25 Jan 2008 11:02:36 Wayne Fay wrote: This is most likely due to transitive dependencies, as you thought. But it sounds a little bit odd as Ant artifacts are mostly used during the build process and not as dependencies. You can use mvn -X package and then search for ant-launcher to see what dependency is bringing it into the build. If you can't figure it out, post your pom.xml and the mvn -X output at pastebin.org or similar and send links. Someone can take a look and try to help you figure it out. Wayne On 1/24/08, Jeudy, Guillaume [EMAIL PROTECTED] wrote: Hi all, I get a list of jars that are added to my war without me specifying it anywhere in my pom.xml as a dependency. Is it because of the dependency transitivity feature ? My pom.xml uses: packagingwar/packaging some jars are added in WEB-INF/lib inside the war file even though they are not listed anywhere in dependencies: here are some of them: [DEBUG] adding entry ant-1.6.5.jar [DEBUG] adding entry ant-junit-1.6.5.jar [DEBUG] adding entry ant-launcher-1.6.5.jar [DEBUG] adding entry antlr-2.7.5.jar [DEBUG] adding entry asm-2.2.jar I could manually exclude them using warSourceExcludesfilelist/warSourceExcludes in the war plugin config but I'd rather understand what is causing this ? I'm using Maven 2.0.8. Thanks, -Guillaume Jeudy _ ___ This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for seperate releases of parent and modules
annoying indeed but you only have to set the scm urls once in the each artifact and with an archetype well only once. i think its dumb to have the parent of several modules the same... if you think OO then the parent of any artifact should define common behaviour for articfacts of that type... so you should have a jar parent, webapp parent etc etc... and usually an aggregation of modules crosses concerns e.g. server, client, common code, persistence, api it seems really obvious to me, maybe i'm missing something On Mon, 21 Jan 2008 22:52:09 Jochen Wiedmann wrote: On Jan 21, 2008 10:42 AM, [EMAIL PROTECTED] wrote: Is it advisable to move the commons-parent to another subdirectory or is this layout the preferred way? I was experiencing with the former, but gave it up. The reason is that far too many plugins are not suitable to use it. Examples include: - The SCM URL must be configured in every subproject. Otherwise the SCM links on the generated site will be broken. - The distribution URL's must be configured in every subproject. Otherwise deployment will use the wrong target URL. And so on. Jochen -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoid Dependency version
In order to have a stable system you MUST understand what the latest release means... if you introduce this into your build you have no control over what actually ends up in it. As an end user this is not a huge deal directly except when people start using RELEASE/STABLE in libraries in the main repositories What is the latest STABLE release? it really depends on your use case. Perhaps a better solution would be to add more metadata into the repository releated to outstanding issues in jira for a particular release. You could then say i would like the latest build with no bugs or critical issues or just no critical issues With RELEASE you end up using the latest released code of every project and the shit hits the fan, you might as well build all the projects from source yourself! i vote a big (non binding ;-) -1 for MNG-2431 if you really want to have an unstable project then use the [0,) range but don't encourage people with nice looking tags... On Tue, 22 Jan 2008 02:32:28 Tomasz Pik wrote: On Jan 21, 2008 2:21 PM, Guillaume Lederrey [EMAIL PROTECTED] wrote: On 20/01/2008, Brian E. Fox [EMAIL PROTECTED] wrote: You can use dependencyManagment in a parent pom to avoid specifying the version in all your child poms. If you really want the latest you have two choices: LATEST - latest snapshot RELEASE - latest release Or you could specify a range like [0,) Probably a dummy question on my part : I can get ranges to work, but not RELEASE nor LATEST. If y put the version of a dependency to either, I get : [INFO] Failed to resolve artifact. Missing: -- 1) myGroup:myProject:jar:RELEASE And the usual dependency not found, would you like to install it message. I tried to find docs, but found not much. Do you know since which version of maven this is available ? As far as I know it works only for plugins. For general usage - please, vote here, maybe this issue will get some attention: http://jira.codehaus.org/browse/MNG-2431 Regards, Tomek Thanks ! -Original Message- From: amit kumar [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 8:38 AM To: Maven Users List Subject: Avoid Dependency version Hi, Can I make it possible for my dependencies(jar files) declared in dependency tags, not have version. Just like in case of plugin it happens, the latest on gets fetched? When I don't put a version in my dependency tag, it throws error. Regards, Amit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jabber : [EMAIL PROTECTED] Skype : Guillaume.Lederrey Projects : * http://rwanda.wordpress.com/ * http://rwandatech.wordpress.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] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: design question: How to easily build a tree of projects?
i have a tree of modules projects to aggregate all of my projects together for CI, it works very well... NOTE the modules projects are not parents but siblings of the modules they aggregate On Tue, 22 Jan 2008 01:43:50 Jan Torben Heuer wrote: Hi, I have a tree of projects which depend on each other and of course its parents. It is a xmlbeans schema tree, but that should not matter. Right now, I have simple projects in the filesystem, but it is very hard to compile or built them, because I have to invoke maven on each project. Is there is simpler way? Can I nest multi-module-projects? Or is there a plugin that automatically traverses a directory and builds each project? What would you suggest? Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoid Dependency version
On Sun, 20 Jan 2008 17:16:46 Brian E. Fox wrote: You can use dependencyManagment in a parent pom to avoid specifying the version in all your child poms. If you really want the latest you have I thought the depedencyManagement section was going away in 2.1 because its a poor implentation of an externalised version manifest... why not use version ranges they work very well, and give you a bit more control over your deliverables. RELEASE and LATEST I guarantee will cause you grief, and IMHO contrary to what is emerging as best practice. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
