|
[
Permlink
| « Hide
]
Andreas Hochsteger added a comment - 13/Aug/06 01:59 PM
First version of the tool.
Andreas Hochsteger made changes - 13/Aug/06 01:59 PM
Bruno created something similar (for Maven 1) in the Daisy project: http://svn.cocoondev.org/viewsvn/trunk/daisy/tools/artifacter/
I'd vote -1 on such a tool. The correct approach is to fix http://jira.codehaus.org/browse/MNG-1577.
Ralph, I think Andreas' tool is merely meant to avoid having to update 20 poms to the next snapshot version of a module when you release that module. MNG-1577 is about something entirely different.
Yes, this is what I intended with this tool.
I didn't know about Bruno's artifacter. It seems to provide much more functionality than mine. OTOH the one I uploaded is a very simple and pragmatic approach to reduce our manual work (and errors) during releases now. But in general I think that this functionality should be part of the maven release plugin ... Jorg,
What do you thing MNG-1577 is about? In Maven 1 you could create a build.properties file and put the version of every jar you wanted to use. You could share that property file across multiple projects so they would all be in synch. Maven 2 provides a similar concept in that it allows you to specify the version of a dependency in the root pom's dependencyManagement section. The problem with the implementation in Maven 2 is that, unlike Maven 1, it is not an override - so if a transitive dependency (or any dependency for that matter) specifies a version the version specified in the dependencyManagement section is not used. Fixing MNG-1577 would mean that to keep all 20 poms in synch would mean updating the dependencyManagement section in the root pom. versions in child poms would be meaningless. That is why I am -1 on the fix proposed here as it is simply a hack to get around a real problem in Maven. Please go to MNG-1577 and add your vote to that issue instead of looking for workarounds here. Unless you can convince me that this problem has problem has nothing to do with keeping dependency versions in synch across blocks, I will continue to express my -1 on this fix. Andreas' script does not _fix_ anything as such, it is intented to aid ppl when doing releases. There is no need to strongly -1 this, as it's just a little tool in helping us doing releases.
I certainly agree with you that fixing <dependencyManagement> eliminates the need for this tool, but i absolutely don't get why you appear to value a vote for MNG-1577 higher than the contribution of temporary workaround. I should think that would be obvious. I value a vote for MNG-1577 higher because I want a real fix to this problem. I've been looking into what it will take to fix this and might be able to get some time to do it myself. But the real issue is that the Maven developers don't seem to think this is a "real" problem, so the more people who complain the better.
I don't like the tool because it proposes to "solve" the problem in exactly the wrong way - by updating every pom it can find. With the correct approach none of these poms would have a version in them at all. Now, you could go right now to all these poms and remove the versions and then create a master pom with all the correct versions in it. That would be a much better approach. But it won't work unless you disable transitive dependencies. Ralph, I can see your point and I agree that the issue should be solved.
Where I don't really agree with you is that you put down someone's work - even when you're right. It may be that some people may be scared and won't contribute (not talking about me here - I can bear up with that ;-). I don't know Maven as well as you do and so I didn't know about the real problems and their solution. All I did was to automate the manual work that has to be done _now_. And BTW I already voted for MNG-1577 so we can get rid of this script soon ;-). Ralph, we need a solution _now_ and not sometime in the future. You're right that eliminating the problem at its root would be the far better approach but unless you pick up the M2 issue and fix it for us or you do all the work of releasing Cocoon artifacts, I don't think you have the right to veto a script (!).
Well, I do have the right. However, in this case I'll change my veto to a -0 (with caveats). I certainly understand the predicament Cocoon is in - it is holding up my organization from switching from Maven 1 to Maven 2 altogether.
My caveat is that I'd simply like agreement that when this fix is done that Cocoon take advantage of it (frankly, I think that is a no-brainer so I'm not really worried). As far as the root problem goes, since my manager will let me work on the Maven issue on company time I should be able to work on it within the next couple of weeks. First, that's good news that this bug will be fixed soon.
On the vetoing issue: I don't think that anybody here around should throw around with votes/vetos without even having a voting. (yes, I'm guilty myself and learned not to do so anymore). You have the right to do so (I don't know of any policy that forbids answering with +1/0/-1) but I don't think that this leads to productive work - especially in this case as Andreas' script will never be part of a release. I guess in general I agree with you. However, if we go with the Maven fix when it is available it will have an impact on end users. We will need to make our master pom available to them to use to get all the versions Cocoon is using. But you are right that the current tool will be fairly invisible.
thanks Andreas, tested it with Cygwin and works for me. I added it to /cocoon/trunk/tools/pom-updater.
Reinhard Poetz made changes - 06/Dec/06 04:09 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Provide a tool to update artifact versions within multiple POMs
