You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/03/25 18:27:38 UTC
Maven Lint
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. 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.
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.
jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Lint
Posted by Jason van Zyl <ja...@maven.org>.
On 25 Mar 07, at 12:52 PM 25 Mar 07, Milos Kleint wrote:
> On 3/25/07, Jason van Zyl <ja...@maven.org> 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.
>
>
That's what I meant, by itself it's not something that can be used
that won't piss people off. I think the JDOM stuff can be used to
find the location but I think when you get into changing the file and
not touching anything I'm not sure if the XML tools will do that.
>> 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.
Right, this is why using the XML tools as they are probably won't
work. We would need to detect indentation to place new blocks in
there but we should touch any formatting, change indentation or
anything all the XML tools seem to want to do.
>
> When you put project inheritance into picture, it gets even more shady
> for any automated tool to decide what to place where.
>
Yah, I'm not saying this would be easy and really to be useful it
would happen in the IDE and be interactive.
>
>>
>> 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.
Cool, the ultimate ideal would be to use this lint tool from the IDE.
Jason.
>
>>
>> jason.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Lint
Posted by Milos Kleint <mk...@gmail.com>.
On 3/25/07, Jason van Zyl <ja...@maven.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org