On 3/25/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,For things lately that we've been making like the enforcer plugin and the dep analyzer that will look for problems in your depMan I was thinking that we should design for an overall lint mechanism and I am specifically thinking toward 2.1 where we flush out a lot of crap but we need to help users transition. Some things that come to mind are: - the use of ${version}, ${project.version}, ${pom.version} we need to pick one or even find a way to default to the project version - depMan problems caused by non MNG-1577 behavior - unused dependencies - dependency versions not being specified in the top-level project (some POM refactoring I have in mind here for IDEs) As part of this we could rewrite people's POMs, but we need a POM writer that currently doesn't exist. One that will not alter anything except the data being changed. The JDOM writer is close, but not good enough.
why not fix it instead of coming up with yet another solution? it needs rigid testing (which I have no clue how to do in modello) but generally works fine.
I think a combination of a good XML parser that can give us the location of elements we want coupled with a tool that can just step into the location given to us by the XML parser and surgically modify the data. I know there's nothing more annoying for users to have the formatting changed and comments lost, etc.
stepping into a location is fairly easy for stuff like changing a boolean or path value somewhere. For more complex stuff like inserting a profile, removing a dependency it becomes harder especially when you have to deal with the user's comments, custom formatting etc. When you put project inheritance into picture, it gets even more shady for any automated tool to decide what to place where.
So if we are going to start collecting best practices then I think capturing them in a lint type mechanism would be ideal. Along with the tools to help users migrate as they wish. Just something I wanted to get started, and have people think about this instead of making 20 different analysis tools and mini frameworks scattered all over the place.
as long as the analysis tools are make as components in plexus/maven, it should be fairly easy to incorporate in IDEs. I've tried over the weekend with dependency analysis component from shared.
jason. --------------------------------------------------------------------- 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]
