design verification

[Dean Hiller <de...@xsoftware.biz>]

I was wondering if I could help with adding a tool from ant-contrib 
called verifydesign.  Basically, you defined the package dependencies, 
and if they are violated, the build breaks.  It is good for making sure 
developers changes are in compliance with the package design.  I would 
need help in understanding the package design first though.  When done, 
it also gives an xml design document that is guaranteed to be up to 
date(as long as build succeeds). 

Also, don't suppose I could get temporary commit access.  I would love 
to blow away all the unused variables and unused code that eclipse is 
complaining about.  I am not sure how I could submit such a patch as it 
might involve around 100 files being changed.
thanks,
dean


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org

Re: design verification

[Jochen Wiedmann <jo...@gmail.com>]

Dean Hiller wrote:

> I was wondering if I could help with adding a tool from ant-contrib 
> called verifydesign.  Basically, you defined the package dependencies, 
> and if they are violated, the build breaks.  It is good for making sure 
> developers changes are in compliance with the package design.  I would 
> need help in understanding the package design first though.  When done, 
> it also gives an xml design document that is guaranteed to be up to 
> date(as long as build succeeds).

Basically, I'd appreciate such work. However, I know that avoiding the 
build breaks would most possibly force us to introduce another 
subproject (and hence yet another jar file), which is shared by at least 
xs and jaxme core. Is it worth the hazzle?


> Also, don't suppose I could get temporary commit access.  I would love 
> to blow away all the unused variables and unused code that eclipse is 
> complaining about.  I am not sure how I could submit such a patch as it 
> might involve around 100 files being changed.

First of all, if you'd do that much work, then I'd have no problem to 
vote for you as a committer in the end. In the meantime, I'd suggest to 
supply patches one by one. For example class after class, or package 
after package. That would allow to review what comes in.

However, a question: Are you sure, that you are refererring to the 
manually created code and not to the generated? In the latter case: I'd 
definitely did my best to avoid warnings as far as possible. To 
eliminate the remaining warnings is definitely a *very* hard job, unless 
you'd solve it by generating sources for Java 5 and added 
@SuppressWarnings. As far as I am concerned, I'd be happy to accept 
patches doing that and making them optional.


Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org