You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Rex Hoffman <re...@e-hoffman.org> on 2010/11/02 22:27:23 UTC
Auto apache version standard as an enforcer rule?
So I have a desire to have maven check prior versions of an artifact
and determine if the apache version standard is being followed.
I had implemented a patch against the clirr plugin in the mojo project
to do this.
http://jira.codehaus.org/browse/MCLIRR-33
It's been several months and this doesn't appear to be going anywhere.
The patch used clirr's api comparison capabilities and worked as follows:
if a method signature had changed, this was considered a backwards
breaking change, and the major version number was expected to be
incremented
if a new method signature was added, this is considered an
enhancement, and a minor version number was expected to be
incremented.
finally if no API changes occurred, the patch version number was
expected to be incremented.
I would implement this version number comparison as a library so that
the version and release plugin could use it as well.... perhaps, with
as an "auto version"
I see this being particularly useful for API maven projects but could
be used with them all. It had two modes, strict -- demanding that
exactly the calculated version number should be used, and
lax, allowing any new version number, greater than or equal to the
calculated to be used.
Care was taken to treat SNAPSHOT appropriately, and to leave the API
in flux before the 1.0 release (no such thing as a backward breaking
change).
(1.0.1-SNAPSHOT was ignored when testing compatibility of the 1.0.1
release, it only compares to 1.0.0)
I'm of the opinion that this functionality would be incredibly helpful
to both double check and educate the larger maven community.
If I were to clean this up and construct an enforcer rule that
demanded adherence to the letter of the law of the apache version
standard, is something that would be allowed into the maven enforcer
plugin?
Or would the team prefer I continue to try to work the the clirr-mojo?
Give me a firm commitment (contingent on quality of course ) and I
could have this done tonight.
Rex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Sweet. Very much what I was looking for. May also create a set of java 5
annotations mirroring these.
Rex
On Tue, Nov 9, 2010 at 8:51 AM, Mark Hobson <ma...@gmail.com> wrote:
> On 9 November 2010 16:30, Rex Hoffman <re...@e-hoffman.org> wrote:
> > My thoughts exactly on the annotation ie. hosted in a generic context.
> The
> > concern I have is the number of useful open source projects that expose
> > interfaces that clients are not required to implement. Ultimately since
> > this style of checking is primarily used by the devs of the project, I
> can
> > have them define the annotation, and whether it marks an interface as
> > "client implements", or "client does not implement". Those might not be
> the
> > best names for the annotation, as it really would mean 'Client implements
> it
> > and my code will break binary compatibility, by calling it at runtime".
>
> Note that Eclipse's PDE has Javadoc tags for these notions:
>
>
> http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Auto apache version standard as an enforcer rule?
Posted by Mark Hobson <ma...@gmail.com>.
On 9 November 2010 16:30, Rex Hoffman <re...@e-hoffman.org> wrote:
> My thoughts exactly on the annotation ie. hosted in a generic context. The
> concern I have is the number of useful open source projects that expose
> interfaces that clients are not required to implement. Ultimately since
> this style of checking is primarily used by the devs of the project, I can
> have them define the annotation, and whether it marks an interface as
> "client implements", or "client does not implement". Those might not be the
> best names for the annotation, as it really would mean 'Client implements it
> and my code will break binary compatibility, by calling it at runtime".
Note that Eclipse's PDE has Javadoc tags for these notions:
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Jesse Glick <je...@oracle.com>.
On 11/09/2010 11:30 AM, Rex Hoffman wrote:
> The only current problem is that it's not in the maven repo.
True. Probably not hard to fix, if that is the only obstacle; take it off list if interested.
> I don't suppose your teams usage of it is based off on an open source ant task?
Currently we are using it via http://hg.netbeans.org/apitest/ which seems to inline the original project's code (not sure why offhand). Probably not relevant to use from
a Maven plugin.
> Though cutting a new interface is generally better programming, I don't
> want this tool to force developers to do that. I want this to be easily
> adopted by as many projects as possible.
Agreed, I just think the _default_ policy should be binary compatibility as defined by http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html - you should
need to declare alternate policies somehow. (It is also safer to flag a change as incompatible, and have the developer indicate that it is OK in order to fix the build,
than to silently claim that changes were compatible when the developer was not even aware of the possible breakage.)
> Would the ability to configure the annotation and whether the plugin should
> use binary or source compatibility when evaluating the interface/abstract
> class meet your needs for QualifiedPublic?
No, @QualifiedPublic works differently. (Again, @QP is just an idle experiment at this point.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Thanks for the insightful comments!
I'll definitely take a look at sigtest. The gpl v2 w/ classpath exception
should be fine. The only current problem is that it's not in the maven
repo. I don't suppose your teams usage of it is based off on an open source
ant task?
Simply based on the activity of the project (recent releases) it might be a
better call than clirr. Also good to have a dev team to report bugs to.
My thoughts exactly on the annotation ie. hosted in a generic context. The
concern I have is the number of useful open source projects that expose
interfaces that clients are not required to implement. Ultimately since
this style of checking is primarily used by the devs of the project, I can
have them define the annotation, and whether it marks an interface as
"client implements", or "client does not implement". Those might not be the
best names for the annotation, as it really would mean 'Client implements it
and my code will break binary compatibility, by calling it at runtime".
I've seen code that uses reflection to deal to deal with enhanced apis,
calls the method if it exists, otherwise not call it and carry on. It was a
pretty nifty way of handling the problem. And with tools like
fest-reflect<http://fest.easytesting.org/>,
wasn't incredibly ugly. So I want to make sure the toolset handles this
case. Though cutting a new interface is generally better programming, I dont
want this tool to force developers to do that. I want this to be easily
adopted by as many projects as possible.
Would the ability to configure the annotation and whether the plugin should
use binary or source compatibility when evaluating the interface/abstract
class meet your needs for QualifiedPublic?
something like
<configuration>
<annotation>org.blah.ClientImplementsAllMethods</annotation>
<clientsExpectedToImplementAllMethods>false</clientsExpectedToImplementAllMethods>
</configuration>
or
<configuration>
<annotation>org.blah.ClientMayNotImplementAllMethods</annotation>
<clientsExpectedToImplementAllMethods>true</clientsExpectedToImplementAllMethods>
</configuration>
Where the annotation class is optional and as no default, and
the clientsExpectedToImplementAllMethods is false.
Rex
On Tue, Nov 9, 2010 at 4:58 AM, Jesse Glick <je...@oracle.com> wrote:
> On 11/08/2010 02:21 AM, Rex Hoffman wrote:
>
>> project: java-version-delta
>>
>
> By the way, you should look at https://sigtest.dev.java.net/ if you have
> not done so already. I'm not sure if the license & feature set suits your
> needs but it would make a potentially useful alternate impl. This is the
> tool used by some of Oracle's teams to check (primarily binary)
> compatibility of Java APIs.
>
> My background: for netbeans.org API modules we run this tool to check for
> compatible & incompatible changes among packages marked public. Currently we
> have an idiosyncratic Ant build (is there any other kind?) so comparisons
> are done against the modules as they existed in the last product release,
> but of course in a Maven setup we would use the policy you are proposing:
> x.y -> x.(y+1) may have compatible but not incompatible changes, etc.
>
>
> The apache portable runtime version standard does want the name of a
>> library
>> to include it's major version number, so for ubuntu/debian xerces look
>> like:
>> libxerces2-java_2.9.0-1_all.deb
>>
>
> Not sure this is applicable to most Java development. If you are using a
> container (such as OSGi) which supports class loader isolation, *and* this
> container permits multiple components with the same ID (but possibly
> different versions) to be loaded in parallel, then it is unnecessary.
> Containers with isolation but which enforce uniqueness on loaded IDs might
> benefit, so long as it really makes sense to load two copies of the
> component - true for plain old class libraries, not necessarily true for
> "active" components which might register services of some sort. Apps not
> using a container are unlikely to benefit since you could only use multiple
> versions of a library in case the package hierarchy was also renamed.
> Anyway, I agree that this is not likely something that an API compatibility
> plugin should address (a separate enforcer rule would suffice).
>
> the default would be to
>> assume that a client of an artifact is not expected to implement [any
>> interfaces]
>>
>
> This seems like a poor default - directly contradicts the longstanding Java
> compatibility policy. (*) If anything, I would place the burden on API
> designers who publish interfaces (or abstract classes) they expect no one
> else to implement, despite there being no such enforcement from the Java
> language. (**) An annotation for this purpose makes some sense, but it would
> have to be hosted in a very generic place quite unrelated to a Maven plugin.
> In the short term, plugin configuration to exclude implements checking on
> certain types or packages may be a better workaround.
>
> (*) For binary compatibility it is permitted to add an interface method
> without breaking existing implementers, so long as this method is never
> called - but that condition is unlikely, since why would there be a method
> no one is calling? You cannot even check whether a given object implements a
> new method or not without using reflection. Better to just introduce a new
> interface (possibly extending the old one) when you want to change
> signatures.
>
> (**) If the API designer wants, it is possible to expose an abstract class
> which can be implemented only within the same component. JSR 294 would be
> very helpful here, but it is possible today so long as all the
> implementations are in the same package, *or* the component uses a format
> (such as OSGi bundle) which permits restrictions on the exported types or
> packages. In http://bitbucket.org/jglick/qualifiedpublic I have been
> playing with a more fine-grained system but for now it requires javac from
> JDK 7.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Auto apache version standard as an enforcer rule?
Posted by Mark Hobson <ma...@gmail.com>.
On 10 November 2010 14:02, Jesse Glick <je...@oracle.com> wrote:
> The trouble with Javadoc pseudo-annotations is that they are unavailable in
> bytecode and thus invisible to a tool like sigtest. I don't know about
> Clirr. I suspect this particular set of Javadoc tags was designed with
> Eclipse editor hints in mind, which probably have access to HTML Javadoc of
> APIs if not the original source project, and possibly predated JSR 175.
>
> Furthermore, they will (ironically enough) not appear in the Javadoc HTML
> output by default, unlike a true @Documented annotation. The burden is on
> the library developer to remember to pass a complex argument such as -tag
> noimplement:t:"Do Not Implement" to the javadoc tool for each such
> annotation in use.
>
> Also consider other tools which might want to analyze this information -
> such as FindBugs, or a hypothetical annotation processor that verified that
> a @NoImplement interface was not in fact implemented except by authorized
> providers.
I certainly agree that some JSR-175 annotations for these concepts
would be best. I'd be surprised if the Eclipse folks haven't got this
on their road map already, might be worth checking.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Jesse Glick <je...@oracle.com>.
On 11/09/2010 07:07 PM, Rex Hoffman wrote:
> I'm leaning to using the (javadoc) annotations
The trouble with Javadoc pseudo-annotations is that they are unavailable in bytecode and thus invisible to a tool like sigtest. I don't know about Clirr. I suspect this
particular set of Javadoc tags was designed with Eclipse editor hints in mind, which probably have access to HTML Javadoc of APIs if not the original source project, and
possibly predated JSR 175.
Furthermore, they will (ironically enough) not appear in the Javadoc HTML output by default, unlike a true @Documented annotation. The burden is on the library developer
to remember to pass a complex argument such as -tag noimplement:t:"Do Not Implement" to the javadoc tool for each such annotation in use.
Also consider other tools which might want to analyze this information - such as FindBugs, or a hypothetical annotation processor that verified that a @NoImplement
interface was not in fact implemented except by authorized providers.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Fully understood. A built in limitation of osgi is package level control,
as opposed to class.
I'm leaning to using the (javadoc) annotations Mark pointed out, They seem a
better way to modify the default clirr/sigtest severity behavior.
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm
Where the annotation would be able to push the severity of the addition of a
method to an interface down from "backwards breaking" to "enhancement" with
@noextends and @noimplement. Any change would be ignored with a
@noreference. @nooverride would probably have no meaning for
now. @noinstantiate could make changes to a constructor a no-op.
What do you think? Rigid default behavior with these as the escape hatch?
I'll ping the eclipse folks and see what they think, see if they have
advice on the use of these.... I think I'll implement this as a
separate jar that filters the results of the java-version-delta, not part of
the default behavior. That way it could be used with an osgi-version-delta,
provided the OsgiDelta class extends the JavaDelta class (represents one
change to one class) , and other filters could replace it if this is found
to be lacking. I could also a default @noextends and @noimplement filter to
allow existing opensource api projects to adopt this without issue.
I think we've hashed it out (and grew the scope) enough. This'll chew up
all my free time for the next two-three weeks.
As soon as I have all the interfaces built out and playing nice together (at
least printing out the deltas) I'll post it to github or
something similar and update this thread if anyone is interested in looking
at it, so it can benefit from early criticism.
Rex
On Tue, Nov 9, 2010 at 2:47 PM, Jesse Glick <je...@oracle.com> wrote:
> On 11/09/2010 02:21 PM, Rex Hoffman wrote:
>
>> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>>
>
> Take note of the distinction made on pp. 5-6 between "interface" and
> "package". Without some special annotations, it is not possible for a tool
> to mechanically decide whether a given interface is intended to be used by a
> consumer and implemented by a provider, or vice-versa (or some more complex
> combination).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Rex
(415) 273-9438
http://www.e-hoffman.org
Re: Auto apache version standard as an enforcer rule?
Posted by Jesse Glick <je...@oracle.com>.
On 11/09/2010 02:21 PM, Rex Hoffman wrote:
> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
Take note of the distinction made on pp. 5-6 between "interface" and "package". Without some special annotations, it is not possible for a tool to mechanically decide
whether a given interface is intended to be used by a consumer and implemented by a provider, or vice-versa (or some more complex combination).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Very cool. I'll have to check that out as well to determine how BND decided
to calculate version numbers, though it's not directly applicable as osgi
creates versions at the package level.
Osgi semantic versioning<http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf>
seems
to extend the ideas in the apache apr, and uses the terms: consumes and
provides to make clear the role an package plays at runtime.
At the very least this indicates the need to support several different
versioning standards (apr and osgi semantic versionsing). I really like
the idea that an api can have consumers and providers, and that they are not
mutually exclusive in the same artifact. From the bnd guy
himself<http://www.aqute.biz/Bnd/Versioning>
.
Makes me think about maven scopes, perhaps allow for "consumes" and
"provides", and default the current compile scope to be both. Or maybe not.
OSGi seems to need more info than maven can provide to auto build the
manifests.
Just makes me believe Jesse is correct about interfaces/abstract classes.
Default to any change being a break in backwards compatibility, but provide
ability to be more lax for api jar files by letting developers alter
default behavior.
Rex
On Tue, Nov 9, 2010 at 9:51 AM, David Jencks <da...@yahoo.com> wrote:
> The BND tool used in the (misnamed) felix maven-bundle-plugin has, in
> recent versions not yet used in the maven-bundle plugin, some logic to
> determine whether an Import-Package constraint is "uses" or "implements" and
> decides which segment of the version number to increment based on that.
>
> might be useful...
> david jencks
>
> On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote:
>
> > On 11/08/2010 02:21 AM, Rex Hoffman wrote:
> >> project: java-version-delta
> >
> > By the way, you should look at https://sigtest.dev.java.net/ if you have
> not done so already. I'm not sure if the license & feature set suits your
> needs but it would make a potentially useful alternate impl. This is the
> tool used by some of Oracle's teams to check (primarily binary)
> compatibility of Java APIs.
> >
> > My background: for netbeans.org API modules we run this tool to check
> for compatible & incompatible changes among packages marked public.
> Currently we have an idiosyncratic Ant build (is there any other kind?) so
> comparisons are done against the modules as they existed in the last product
> release, but of course in a Maven setup we would use the policy you are
> proposing: x.y -> x.(y+1) may have compatible but not incompatible changes,
> etc.
> >
> >> The apache portable runtime version standard does want the name of a
> library
> >> to include it's major version number, so for ubuntu/debian xerces look
> like:
> >> libxerces2-java_2.9.0-1_all.deb
> >
> > Not sure this is applicable to most Java development. If you are using a
> container (such as OSGi) which supports class loader isolation, *and* this
> container permits multiple components with the same ID (but possibly
> different versions) to be loaded in parallel, then it is unnecessary.
> Containers with isolation but which enforce uniqueness on loaded IDs might
> benefit, so long as it really makes sense to load two copies of the
> component - true for plain old class libraries, not necessarily true for
> "active" components which might register services of some sort. Apps not
> using a container are unlikely to benefit since you could only use multiple
> versions of a library in case the package hierarchy was also renamed.
> Anyway, I agree that this is not likely something that an API compatibility
> plugin should address (a separate enforcer rule would suffice).
> >
> >> the default would be to
> >> assume that a client of an artifact is not expected to implement [any
> interfaces]
> >
> > This seems like a poor default - directly contradicts the longstanding
> Java compatibility policy. (*) If anything, I would place the burden on API
> designers who publish interfaces (or abstract classes) they expect no one
> else to implement, despite there being no such enforcement from the Java
> language. (**) An annotation for this purpose makes some sense, but it would
> have to be hosted in a very generic place quite unrelated to a Maven plugin.
> In the short term, plugin configuration to exclude implements checking on
> certain types or packages may be a better workaround.
> >
> > (*) For binary compatibility it is permitted to add an interface method
> without breaking existing implementers, so long as this method is never
> called - but that condition is unlikely, since why would there be a method
> no one is calling? You cannot even check whether a given object implements a
> new method or not without using reflection. Better to just introduce a new
> interface (possibly extending the old one) when you want to change
> signatures.
> >
> > (**) If the API designer wants, it is possible to expose an abstract
> class which can be implemented only within the same component. JSR 294 would
> be very helpful here, but it is possible today so long as all the
> implementations are in the same package, *or* the component uses a format
> (such as OSGi bundle) which permits restrictions on the exported types or
> packages. In http://bitbucket.org/jglick/qualifiedpublic I have been
> playing with a more fine-grained system but for now it requires javac from
> JDK 7.
> >
> >
> > ---------------------------------------------------------------------
> > 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: Auto apache version standard as an enforcer rule?
Posted by David Jencks <da...@yahoo.com>.
The BND tool used in the (misnamed) felix maven-bundle-plugin has, in recent versions not yet used in the maven-bundle plugin, some logic to determine whether an Import-Package constraint is "uses" or "implements" and decides which segment of the version number to increment based on that.
might be useful...
david jencks
On Nov 9, 2010, at 4:58 AM, Jesse Glick wrote:
> On 11/08/2010 02:21 AM, Rex Hoffman wrote:
>> project: java-version-delta
>
> By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license & feature set suits your needs but it would make a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs.
>
> My background: for netbeans.org API modules we run this tool to check for compatible & incompatible changes among packages marked public. Currently we have an idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup we would use the policy you are proposing: x.y -> x.(y+1) may have compatible but not incompatible changes, etc.
>
>> The apache portable runtime version standard does want the name of a library
>> to include it's major version number, so for ubuntu/debian xerces look like:
>> libxerces2-java_2.9.0-1_all.deb
>
> Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true for "active" components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate enforcer rule would suffice).
>
>> the default would be to
>> assume that a client of an artifact is not expected to implement [any interfaces]
>
> This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements checking on certain types or packages may be a better workaround.
>
> (*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures.
>
> (**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here, but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7.
>
>
> ---------------------------------------------------------------------
> 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: Auto apache version standard as an enforcer rule?
Posted by Jesse Glick <je...@oracle.com>.
On 11/08/2010 02:21 AM, Rex Hoffman wrote:
> project: java-version-delta
By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license & feature set suits your needs but it would make
a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs.
My background: for netbeans.org API modules we run this tool to check for compatible & incompatible changes among packages marked public. Currently we have an
idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup
we would use the policy you are proposing: x.y -> x.(y+1) may have compatible but not incompatible changes, etc.
> The apache portable runtime version standard does want the name of a library
> to include it's major version number, so for ubuntu/debian xerces look like:
> libxerces2-java_2.9.0-1_all.deb
Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits
multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce
uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true
for "active" components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a
library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate
enforcer rule would suffice).
> the default would be to
> assume that a client of an artifact is not expected to implement [any interfaces]
This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish
interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose
makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements
checking on certain types or packages may be a better workaround.
(*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that
condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using
reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures.
(**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here,
but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on
the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Been hacking through this today:
current structure/status:
project: version-delta-api: not tied to any particular programming language,
comparator which can be passed a listener, listener receive each delta as
calculated -- can be passed ignore file ant include/exclude strings, defines
severity: backwards-breaking, enhancement, and internal (for a no-op).
project: java-version-delta: delta implementation understands java
class/methods/fields etc, putting clirr style delta messages into an enum
which doesn't have an dependency on clirr.
project: artifact-file-util: look up artifacts, download them and read their
contents.
project: clirr-java-version-delta: implements java-version-delta, uses
artifact-file-util.
project: apache-version-standard: service returns recommend version number
after comparing against the latest released version number, relies on
listener to output api differences, and determine highest level of api
change, to determine which version number to return. Currently building the
system to prevent the use of buildnumber and qualifiers other than on
snapshots, as nothing exists mentioning them in the apr
http://apr.apache.org/versioning.html
The apache portable runtime version standard does want the name of a library
to include it's major version number, so for ubuntu/debian xerces look like:
libxerces2-java_2.9.0-1_all.deb, with a similar pattern on the jar
names. Not proposing doing anything about the naming, just noting the
delta. Enforcing/Tracking deltas to the api and suggesting version numbers
seems sufficient to me.
soon a rule to wrap it all up....
The clirr plugin supports an edge case of a project being compared against
several jar files, to determine the delta from the project to all the jars,
I'm leaving method signatures in place to support this, but not currently
target it for implementation in the enforcer rule.
It's coming together, but only about 12 hours in, expect it'll take a
another 30 hours or so as I had to reacquaint myself with the
clirr-maven-plugin code which is highly coupled, making separating these
projects out fairly tedious, especially the artifact-file-util which I hope
can be used on similar projects to scala-version-delta, ruby-version-delta,
etc.
On to a proposal:
Thinking of creating a @ClientImplements annotation to specify when an api
expects a consumer (not a provider / implementation) of a library to have a
class implement an interface or extend an abstract class. This would
determine if a change to that interface (or abstract method add to class) is
a backwards breaking change or an enhancement, the default would be to
assume that a client of an artifact is not expected to implement and
api/extend an abstract class making the change an enhancement.
Though I'm wondering if developers where planning on running with something
like <scope>implements</scope> briefly mentioned in this
thread<http://mail-archives.apache.org/mod_mbox/maven-dev/201011.mbox/%3CAANLkTi=uV7RpGdCDnE_sr11+GyHZJf74VKC11RVsHwr4@mail.gmail.com%3E>
and
what the intent might be:
I dont' see how it could help (an api jar made entirely of interfaces could
always provide an interface it expects a client --of an implementation of
that api-- to implement). The listener interface in the version-delta-api
I'm building is an example of this.
I'm normally not a fan of framework annotations in code, but something like
this annotation would help to more clearly define an api. Given how
uncommon/onerous it is to demand client implement
an interface (though maybe I shouldn't say this while proposing to expose a
listener pattern over the version-delta-api) I don't think it would be
overly demanding to ask a dev who want to use these versioning tools to
track their projects use this kind of annotation.
Potential the library could simply be told which annotation to look for,
rather than providing a default annotation?
Weighing options, Looking for feedback, ideas to make it better, etc....
Thanks,
Rex
On Fri, Nov 5, 2010 at 2:07 PM, Rex Hoffman <re...@e-hoffman.org> wrote:
> Really, this is a question of how apache maven wants to approach the apache
> version standard. I'm begin to believe it would be bad form to rely on a
> mojo plugin to do this. It would also be inappropriate to build the
> functionality into maven proper as well (as part of the
> DefaultArtifactVersion) as other version standards may be used by an
> organization. At least being a part of an official maven plugin gives it
> more credence, and sets a path for supporting other competing version
> standard support (if they exist).
>
> The version plugin probably shouldn't break a build. But maybe it should
> be able to determine the next appropriate version based on the code and
> apache version standards. A library that abstracts the mechanism used could
> be helpful in this, which is probably something I should write that wraps
> clirr.
>
> Back to the mojo though:
>
> I had reworked it. With in a week or two of the discussion
> that occurred on the mojo mailing list. I had split the functionality into
> multiple patches (I had added other functionality at the same time).
>
> The only remaining question as far, as I know, was whether I should create
> a helper class for storing version numbers or use the
> DefaultArtifactVersion. The last message in the thread was that I should
> not rely on DefaultArtifactVersion, as it could potentially couple the
> plugin to a particular version of maven. I took that to mean it should
> continue to use the ApacheVersionNumber class that I had originally written
> as any reliance on the DefaultVersionNumber could break functionality.
>
> Also, I believe an ApacheVersionNumber class should exist. Though it should
> implement the ArtifactVersion interface, and exist outside of the clirr
> plugin.
>
> When I saw my dependency-convergence-rule patch quickly applied to the
> enforcer plugin (which several mojo devs felt was the right place for the
> the apache version number functionality anyway) I reweighed the benefits of
> building this into clirr.
>
> 1) Being part of enforcer probably means it's more likely to be noticed and
> used.
> 2) Clirr plugin seems stagnant and infrequently updated.
> 3) Building a rule that happens to use clirr seems more maven like to me.
> It's more declarative.... The devs using it wont care about the underling
> functionality.
> 4) Should animal sniffer or some other toolset later prove to be more
> effective and flexible, we can change it without expecting devs to change
> their poms.
> 5) An underling apache version standard library could be used by multiple
> plugins, not just to break the build -- but in the case of the version
> plugin, update the version appropriately without the need for input.
>
> In short I think it's better to build maven's implementation of the apache
> version standard than the clirr plugin's implementation of the apache
> version standard.
>
> So the real question is then, how do apache maven team members want to
> handle version standards. Right now they are silently ignored, no though is
> put into handling milestone releases. Or release candidates. Or nightly
> builds. A mess had been growing in the way spring and hibernate name there
> releases, potential breaking version ranges. Apache maven is in a position
> to encourage good behavior. I think this would help.
>
> I also believe the same kind or opportunity to create a source control
> branch policy library exists in maven. Though it's benefits are not as
> widely felt.
>
> When the release plugin doesn't need anywhere near as much input as it does
> now, I'll feel like this work is done.
>
> Sorry for the long email. Just wanted to be as clear as I can on my
> current reasonings, and see if the members agree. I wouldn't mind doing the
> work, as long as it gets used.
>
> Rex
>
>
> On Fri, Nov 5, 2010 at 12:08 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> I thought you were going to rework the patch...
>>
>> If you have reworked the patch, then ping the dev@mojo list again...
>>
>> given that the feeling is that m-enforcer-p is not a good fit (because
>> of phases)
>>
>> and given that v-m-p is not a good fit (because I'm going to insist
>> that v-m-p does not have anything to do with failing the build),
>> clirr-m-p is the natural home of your extended functionality...
>>
>> if you are providing a clean patch which uses a helper method to
>> delegate to DefaultArtifactVersion, then I cannot see why this will
>> not be applied
>>
>> -Stephen
>>
>> On 5 November 2010 18:53, Rex Hoffman <re...@e-hoffman.org> wrote:
>> > Hmm... good point about the phase.... i'll have to think on that. We
>> can
>> > always have two executions for the plugin, or perhaps the plugin should
>> > allow a rule to specify what phase it wants to be run in, thought that
>> would
>> > be harder to pull off. Though probably more correct.
>> >
>> > I have already written this version check as a patch for clirr.
>> > The current maintainers just seem unwilling to adopt it.
>> > See: http://jira.codehaus.org/browse/MCLIRR-33
>> >
>> > Also have it compiled here:
>> >
>> https://www.e-hoffman.org/released/repo/org/codehaus/mojo/clirr-maven-plugin/2.3.0/
>> >
>> > Usage is as simple as:
>> >
>> > <configuration>
>> >
>> <failBasedOnApacheVersionNumberStandard>true</failBasedOnApacheVersionNumberStandard>
>> > <strictVersionNumber>true</strictVersionNumber>
>> > </configuration>
>> >
>> > MNG-3826 is unnecessary, because the clirr plugin itself can make the
>> > distinction, simply by looking at your current version number and all
>> prior
>> > released version.
>> >
>> > Also, from there it's not hard to ensure no visible changes on patch
>> number.
>> >
>> > I do think I need to go in an change the behavior for interfaces.
>> Currently
>> > clirr thinks any change to an interface is backwards breaking... on the
>> > assumption that every consumer of the jar will implement that interface.
>> I
>> > don't believe most developers work that way with interfaces anymore.
>> In
>> > general I think we work more like slf4j, where we define an API made of
>> > interfaces in a jar. Some packages implement it (so the changes for
>> them
>> > force code changes -- which is to be expected and wont require checking
>> > functionality.... they failed compile will tell the dev what's up). But
>> > almost every other package just uses that API. So my code does have a
>> known
>> > bug I have to clean up.
>> >
>> > But again, the mojo devs have very little interest in this, and I'd
>> rather
>> > we have a apache version standard plugin that happens to use clirr,
>> rather
>> > than a clirr plugin that happens to enforce the apache version standard.
>> >
>> > Rex
>> >
>> > On Fri, Nov 5, 2010 at 3:32 AM, Mark Hobson <ma...@gmail.com>
>> wrote:
>> >
>> >> On 4 November 2010 18:28, Rex Hoffman <re...@e-hoffman.org> wrote:
>> >> > Seems reasonable, build a helper library to run clirr and analyze
>> it's
>> >> > results, allow the clirr plugin to use it in it's existing manner, or
>> by
>> >> an
>> >> > enforcer rule.
>> >> >
>> >> > That fact that it's clirr under the hood of that enforcer rule will
>> be
>> >> > completely abstracted. This will be a rule to enforce apache version
>> >> > standard, that happens to use clirr. I'll write a clean api for it's
>> >> > analysis provider (clirr).
>> >> >
>> >> > I know it'll be annoying, that's kinda the point. If your working on
>> a
>> >> > 1.1-SNAPSHOT and create a backwards breaking change, you have messed
>> up.
>> >> > The rule will tell the dev to correct the method, or bump the
>> version
>> >> > number to 2.0-SNAPSHOT. The real danger is a dev not being aware
>> that
>> >> they
>> >> > have produced a backwards breaking change. Again, very helpful for
>> apis.
>> >> >
>> >> > Given Brett's email today citing the desire for
>> >> >
>> >> > "
>> >> > Configurable conflict resolution strategy - newest, oldest that
>> satisfies
>> >> > Enforcer rule to lock down above
>> >> > Importance of specificity, not magic - break the build if conflicting
>> >> > versions, not try and solve it
>> >> > Be deterministic is maven's strength
>> >> > "
>> >> >
>> >> > I think it's important we codify how maven wants devs to think about
>> >> > versions. Right now it a snapshot or release. The ranges have vague
>> >> > meaning at best, not knowing what version policy the project you
>> depend
>> >> on
>> >> > follows.
>> >> >
>> >> > If you want to hold of the release until Monday, I will commit to
>> having
>> >> it
>> >> > done and tested by then??
>> >> >
>> >> > I think having the dependency-convergence rule and this rule will do
>> a
>> >> lot
>> >> > for many organization that have or are adopting maven. I know it
>> >> definitely
>> >> > helped at the last place I worked.
>> >>
>> >> Enforcing no API breaking changes within minor versions has been on my
>> >> wish list for a while too. My plan was to use the Clirr plugin in a
>> >> profile that is only activated for minor versions. This latter point
>> >> requires something like MNG-3826 though.
>> >>
>> >> Personally I feel that this check is beyond the scope of the enforcer.
>> >> By default the enforcer runs at validate phase, way before classes
>> >> are compiled for Clirr, so I'd feel happier achieving this in the
>> >> verify phase using clirr:check. It is a hazy line between enforcer
>> >> rules and other plugin goals, but I'd suggest using rules for (fast)
>> >> environment and POM checks and other plugins for (slower) checks that
>> >> require results of lifecycle phases.
>> >>
>> >> Mark
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Really, this is a question of how apache maven wants to approach the apache
version standard. I'm begin to believe it would be bad form to rely on a
mojo plugin to do this. It would also be inappropriate to build the
functionality into maven proper as well (as part of the
DefaultArtifactVersion) as other version standards may be used by an
organization. At least being a part of an official maven plugin gives it
more credence, and sets a path for supporting other competing version
standard support (if they exist).
The version plugin probably shouldn't break a build. But maybe it should be
able to determine the next appropriate version based on the code and apache
version standards. A library that abstracts the mechanism used could be
helpful in this, which is probably something I should write that wraps
clirr.
Back to the mojo though:
I had reworked it. With in a week or two of the discussion that occurred on
the mojo mailing list. I had split the functionality into multiple patches
(I had added other functionality at the same time).
The only remaining question as far, as I know, was whether I should create a
helper class for storing version numbers or use the DefaultArtifactVersion.
The last message in the thread was that I should not rely on
DefaultArtifactVersion,
as it could potentially couple the plugin to a particular version of maven.
I took that to mean it should continue to use the ApacheVersionNumber
class that I had originally written as any reliance on the
DefaultVersionNumber could break functionality.
Also, I believe an ApacheVersionNumber class should exist. Though it should
implement the ArtifactVersion interface, and exist outside of the clirr
plugin.
When I saw my dependency-convergence-rule patch quickly applied to the
enforcer plugin (which several mojo devs felt was the right place for the
the apache version number functionality anyway) I reweighed the benefits of
building this into clirr.
1) Being part of enforcer probably means it's more likely to be noticed and
used.
2) Clirr plugin seems stagnant and infrequently updated.
3) Building a rule that happens to use clirr seems more maven like to me.
It's more declarative.... The devs using it wont care about the underling
functionality.
4) Should animal sniffer or some other toolset later prove to be more
effective and flexible, we can change it without expecting devs to change
their poms.
5) An underling apache version standard library could be used by multiple
plugins, not just to break the build -- but in the case of the version
plugin, update the version appropriately without the need for input.
In short I think it's better to build maven's implementation of the apache
version standard than the clirr plugin's implementation of the apache
version standard.
So the real question is then, how do apache maven team members want to
handle version standards. Right now they are silently ignored, no though is
put into handling milestone releases. Or release candidates. Or nightly
builds. A mess had been growing in the way spring and hibernate name there
releases, potential breaking version ranges. Apache maven is in a position
to encourage good behavior. I think this would help.
I also believe the same kind or opportunity to create a source control
branch policy library exists in maven. Though it's benefits are not as
widely felt.
When the release plugin doesn't need anywhere near as much input as it does
now, I'll feel like this work is done.
Sorry for the long email. Just wanted to be as clear as I can on my current
reasonings, and see if the members agree. I wouldn't mind doing the work, as
long as it gets used.
Rex
On Fri, Nov 5, 2010 at 12:08 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I thought you were going to rework the patch...
>
> If you have reworked the patch, then ping the dev@mojo list again...
>
> given that the feeling is that m-enforcer-p is not a good fit (because
> of phases)
>
> and given that v-m-p is not a good fit (because I'm going to insist
> that v-m-p does not have anything to do with failing the build),
> clirr-m-p is the natural home of your extended functionality...
>
> if you are providing a clean patch which uses a helper method to
> delegate to DefaultArtifactVersion, then I cannot see why this will
> not be applied
>
> -Stephen
>
> On 5 November 2010 18:53, Rex Hoffman <re...@e-hoffman.org> wrote:
> > Hmm... good point about the phase.... i'll have to think on that. We can
> > always have two executions for the plugin, or perhaps the plugin should
> > allow a rule to specify what phase it wants to be run in, thought that
> would
> > be harder to pull off. Though probably more correct.
> >
> > I have already written this version check as a patch for clirr.
> > The current maintainers just seem unwilling to adopt it.
> > See: http://jira.codehaus.org/browse/MCLIRR-33
> >
> > Also have it compiled here:
> >
> https://www.e-hoffman.org/released/repo/org/codehaus/mojo/clirr-maven-plugin/2.3.0/
> >
> > Usage is as simple as:
> >
> > <configuration>
> >
> <failBasedOnApacheVersionNumberStandard>true</failBasedOnApacheVersionNumberStandard>
> > <strictVersionNumber>true</strictVersionNumber>
> > </configuration>
> >
> > MNG-3826 is unnecessary, because the clirr plugin itself can make the
> > distinction, simply by looking at your current version number and all
> prior
> > released version.
> >
> > Also, from there it's not hard to ensure no visible changes on patch
> number.
> >
> > I do think I need to go in an change the behavior for interfaces.
> Currently
> > clirr thinks any change to an interface is backwards breaking... on the
> > assumption that every consumer of the jar will implement that interface.
> I
> > don't believe most developers work that way with interfaces anymore. In
> > general I think we work more like slf4j, where we define an API made of
> > interfaces in a jar. Some packages implement it (so the changes for them
> > force code changes -- which is to be expected and wont require checking
> > functionality.... they failed compile will tell the dev what's up). But
> > almost every other package just uses that API. So my code does have a
> known
> > bug I have to clean up.
> >
> > But again, the mojo devs have very little interest in this, and I'd
> rather
> > we have a apache version standard plugin that happens to use clirr,
> rather
> > than a clirr plugin that happens to enforce the apache version standard.
> >
> > Rex
> >
> > On Fri, Nov 5, 2010 at 3:32 AM, Mark Hobson <ma...@gmail.com>
> wrote:
> >
> >> On 4 November 2010 18:28, Rex Hoffman <re...@e-hoffman.org> wrote:
> >> > Seems reasonable, build a helper library to run clirr and analyze it's
> >> > results, allow the clirr plugin to use it in it's existing manner, or
> by
> >> an
> >> > enforcer rule.
> >> >
> >> > That fact that it's clirr under the hood of that enforcer rule will be
> >> > completely abstracted. This will be a rule to enforce apache version
> >> > standard, that happens to use clirr. I'll write a clean api for it's
> >> > analysis provider (clirr).
> >> >
> >> > I know it'll be annoying, that's kinda the point. If your working on
> a
> >> > 1.1-SNAPSHOT and create a backwards breaking change, you have messed
> up.
> >> > The rule will tell the dev to correct the method, or bump the version
> >> > number to 2.0-SNAPSHOT. The real danger is a dev not being aware that
> >> they
> >> > have produced a backwards breaking change. Again, very helpful for
> apis.
> >> >
> >> > Given Brett's email today citing the desire for
> >> >
> >> > "
> >> > Configurable conflict resolution strategy - newest, oldest that
> satisfies
> >> > Enforcer rule to lock down above
> >> > Importance of specificity, not magic - break the build if conflicting
> >> > versions, not try and solve it
> >> > Be deterministic is maven's strength
> >> > "
> >> >
> >> > I think it's important we codify how maven wants devs to think about
> >> > versions. Right now it a snapshot or release. The ranges have vague
> >> > meaning at best, not knowing what version policy the project you
> depend
> >> on
> >> > follows.
> >> >
> >> > If you want to hold of the release until Monday, I will commit to
> having
> >> it
> >> > done and tested by then??
> >> >
> >> > I think having the dependency-convergence rule and this rule will do a
> >> lot
> >> > for many organization that have or are adopting maven. I know it
> >> definitely
> >> > helped at the last place I worked.
> >>
> >> Enforcing no API breaking changes within minor versions has been on my
> >> wish list for a while too. My plan was to use the Clirr plugin in a
> >> profile that is only activated for minor versions. This latter point
> >> requires something like MNG-3826 though.
> >>
> >> Personally I feel that this check is beyond the scope of the enforcer.
> >> By default the enforcer runs at validate phase, way before classes
> >> are compiled for Clirr, so I'd feel happier achieving this in the
> >> verify phase using clirr:check. It is a hazy line between enforcer
> >> rules and other plugin goals, but I'd suggest using rules for (fast)
> >> environment and POM checks and other plugins for (slower) checks that
> >> require results of lifecycle phases.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> 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: Auto apache version standard as an enforcer rule?
Posted by Stephen Connolly <st...@gmail.com>.
I thought you were going to rework the patch...
If you have reworked the patch, then ping the dev@mojo list again...
given that the feeling is that m-enforcer-p is not a good fit (because
of phases)
and given that v-m-p is not a good fit (because I'm going to insist
that v-m-p does not have anything to do with failing the build),
clirr-m-p is the natural home of your extended functionality...
if you are providing a clean patch which uses a helper method to
delegate to DefaultArtifactVersion, then I cannot see why this will
not be applied
-Stephen
On 5 November 2010 18:53, Rex Hoffman <re...@e-hoffman.org> wrote:
> Hmm... good point about the phase.... i'll have to think on that. We can
> always have two executions for the plugin, or perhaps the plugin should
> allow a rule to specify what phase it wants to be run in, thought that would
> be harder to pull off. Though probably more correct.
>
> I have already written this version check as a patch for clirr.
> The current maintainers just seem unwilling to adopt it.
> See: http://jira.codehaus.org/browse/MCLIRR-33
>
> Also have it compiled here:
> https://www.e-hoffman.org/released/repo/org/codehaus/mojo/clirr-maven-plugin/2.3.0/
>
> Usage is as simple as:
>
> <configuration>
> <failBasedOnApacheVersionNumberStandard>true</failBasedOnApacheVersionNumberStandard>
> <strictVersionNumber>true</strictVersionNumber>
> </configuration>
>
> MNG-3826 is unnecessary, because the clirr plugin itself can make the
> distinction, simply by looking at your current version number and all prior
> released version.
>
> Also, from there it's not hard to ensure no visible changes on patch number.
>
> I do think I need to go in an change the behavior for interfaces. Currently
> clirr thinks any change to an interface is backwards breaking... on the
> assumption that every consumer of the jar will implement that interface. I
> don't believe most developers work that way with interfaces anymore. In
> general I think we work more like slf4j, where we define an API made of
> interfaces in a jar. Some packages implement it (so the changes for them
> force code changes -- which is to be expected and wont require checking
> functionality.... they failed compile will tell the dev what's up). But
> almost every other package just uses that API. So my code does have a known
> bug I have to clean up.
>
> But again, the mojo devs have very little interest in this, and I'd rather
> we have a apache version standard plugin that happens to use clirr, rather
> than a clirr plugin that happens to enforce the apache version standard.
>
> Rex
>
> On Fri, Nov 5, 2010 at 3:32 AM, Mark Hobson <ma...@gmail.com> wrote:
>
>> On 4 November 2010 18:28, Rex Hoffman <re...@e-hoffman.org> wrote:
>> > Seems reasonable, build a helper library to run clirr and analyze it's
>> > results, allow the clirr plugin to use it in it's existing manner, or by
>> an
>> > enforcer rule.
>> >
>> > That fact that it's clirr under the hood of that enforcer rule will be
>> > completely abstracted. This will be a rule to enforce apache version
>> > standard, that happens to use clirr. I'll write a clean api for it's
>> > analysis provider (clirr).
>> >
>> > I know it'll be annoying, that's kinda the point. If your working on a
>> > 1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
>> > The rule will tell the dev to correct the method, or bump the version
>> > number to 2.0-SNAPSHOT. The real danger is a dev not being aware that
>> they
>> > have produced a backwards breaking change. Again, very helpful for apis.
>> >
>> > Given Brett's email today citing the desire for
>> >
>> > "
>> > Configurable conflict resolution strategy - newest, oldest that satisfies
>> > Enforcer rule to lock down above
>> > Importance of specificity, not magic - break the build if conflicting
>> > versions, not try and solve it
>> > Be deterministic is maven's strength
>> > "
>> >
>> > I think it's important we codify how maven wants devs to think about
>> > versions. Right now it a snapshot or release. The ranges have vague
>> > meaning at best, not knowing what version policy the project you depend
>> on
>> > follows.
>> >
>> > If you want to hold of the release until Monday, I will commit to having
>> it
>> > done and tested by then??
>> >
>> > I think having the dependency-convergence rule and this rule will do a
>> lot
>> > for many organization that have or are adopting maven. I know it
>> definitely
>> > helped at the last place I worked.
>>
>> Enforcing no API breaking changes within minor versions has been on my
>> wish list for a while too. My plan was to use the Clirr plugin in a
>> profile that is only activated for minor versions. This latter point
>> requires something like MNG-3826 though.
>>
>> Personally I feel that this check is beyond the scope of the enforcer.
>> By default the enforcer runs at validate phase, way before classes
>> are compiled for Clirr, so I'd feel happier achieving this in the
>> verify phase using clirr:check. It is a hazy line between enforcer
>> rules and other plugin goals, but I'd suggest using rules for (fast)
>> environment and POM checks and other plugins for (slower) checks that
>> require results of lifecycle phases.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Hmm... good point about the phase.... i'll have to think on that. We can
always have two executions for the plugin, or perhaps the plugin should
allow a rule to specify what phase it wants to be run in, thought that would
be harder to pull off. Though probably more correct.
I have already written this version check as a patch for clirr.
The current maintainers just seem unwilling to adopt it.
See: http://jira.codehaus.org/browse/MCLIRR-33
Also have it compiled here:
https://www.e-hoffman.org/released/repo/org/codehaus/mojo/clirr-maven-plugin/2.3.0/
Usage is as simple as:
<configuration>
<failBasedOnApacheVersionNumberStandard>true</failBasedOnApacheVersionNumberStandard>
<strictVersionNumber>true</strictVersionNumber>
</configuration>
MNG-3826 is unnecessary, because the clirr plugin itself can make the
distinction, simply by looking at your current version number and all prior
released version.
Also, from there it's not hard to ensure no visible changes on patch number.
I do think I need to go in an change the behavior for interfaces. Currently
clirr thinks any change to an interface is backwards breaking... on the
assumption that every consumer of the jar will implement that interface. I
don't believe most developers work that way with interfaces anymore. In
general I think we work more like slf4j, where we define an API made of
interfaces in a jar. Some packages implement it (so the changes for them
force code changes -- which is to be expected and wont require checking
functionality.... they failed compile will tell the dev what's up). But
almost every other package just uses that API. So my code does have a known
bug I have to clean up.
But again, the mojo devs have very little interest in this, and I'd rather
we have a apache version standard plugin that happens to use clirr, rather
than a clirr plugin that happens to enforce the apache version standard.
Rex
On Fri, Nov 5, 2010 at 3:32 AM, Mark Hobson <ma...@gmail.com> wrote:
> On 4 November 2010 18:28, Rex Hoffman <re...@e-hoffman.org> wrote:
> > Seems reasonable, build a helper library to run clirr and analyze it's
> > results, allow the clirr plugin to use it in it's existing manner, or by
> an
> > enforcer rule.
> >
> > That fact that it's clirr under the hood of that enforcer rule will be
> > completely abstracted. This will be a rule to enforce apache version
> > standard, that happens to use clirr. I'll write a clean api for it's
> > analysis provider (clirr).
> >
> > I know it'll be annoying, that's kinda the point. If your working on a
> > 1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
> > The rule will tell the dev to correct the method, or bump the version
> > number to 2.0-SNAPSHOT. The real danger is a dev not being aware that
> they
> > have produced a backwards breaking change. Again, very helpful for apis.
> >
> > Given Brett's email today citing the desire for
> >
> > "
> > Configurable conflict resolution strategy - newest, oldest that satisfies
> > Enforcer rule to lock down above
> > Importance of specificity, not magic - break the build if conflicting
> > versions, not try and solve it
> > Be deterministic is maven's strength
> > "
> >
> > I think it's important we codify how maven wants devs to think about
> > versions. Right now it a snapshot or release. The ranges have vague
> > meaning at best, not knowing what version policy the project you depend
> on
> > follows.
> >
> > If you want to hold of the release until Monday, I will commit to having
> it
> > done and tested by then??
> >
> > I think having the dependency-convergence rule and this rule will do a
> lot
> > for many organization that have or are adopting maven. I know it
> definitely
> > helped at the last place I worked.
>
> Enforcing no API breaking changes within minor versions has been on my
> wish list for a while too. My plan was to use the Clirr plugin in a
> profile that is only activated for minor versions. This latter point
> requires something like MNG-3826 though.
>
> Personally I feel that this check is beyond the scope of the enforcer.
> By default the enforcer runs at validate phase, way before classes
> are compiled for Clirr, so I'd feel happier achieving this in the
> verify phase using clirr:check. It is a hazy line between enforcer
> rules and other plugin goals, but I'd suggest using rules for (fast)
> environment and POM checks and other plugins for (slower) checks that
> require results of lifecycle phases.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Auto apache version standard as an enforcer rule?
Posted by Mark Hobson <ma...@gmail.com>.
On 4 November 2010 18:28, Rex Hoffman <re...@e-hoffman.org> wrote:
> Seems reasonable, build a helper library to run clirr and analyze it's
> results, allow the clirr plugin to use it in it's existing manner, or by an
> enforcer rule.
>
> That fact that it's clirr under the hood of that enforcer rule will be
> completely abstracted. This will be a rule to enforce apache version
> standard, that happens to use clirr. I'll write a clean api for it's
> analysis provider (clirr).
>
> I know it'll be annoying, that's kinda the point. If your working on a
> 1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
> The rule will tell the dev to correct the method, or bump the version
> number to 2.0-SNAPSHOT. The real danger is a dev not being aware that they
> have produced a backwards breaking change. Again, very helpful for apis.
>
> Given Brett's email today citing the desire for
>
> "
> Configurable conflict resolution strategy - newest, oldest that satisfies
> Enforcer rule to lock down above
> Importance of specificity, not magic - break the build if conflicting
> versions, not try and solve it
> Be deterministic is maven's strength
> "
>
> I think it's important we codify how maven wants devs to think about
> versions. Right now it a snapshot or release. The ranges have vague
> meaning at best, not knowing what version policy the project you depend on
> follows.
>
> If you want to hold of the release until Monday, I will commit to having it
> done and tested by then??
>
> I think having the dependency-convergence rule and this rule will do a lot
> for many organization that have or are adopting maven. I know it definitely
> helped at the last place I worked.
Enforcing no API breaking changes within minor versions has been on my
wish list for a while too. My plan was to use the Clirr plugin in a
profile that is only activated for minor versions. This latter point
requires something like MNG-3826 though.
Personally I feel that this check is beyond the scope of the enforcer.
By default the enforcer runs at validate phase, way before classes
are compiled for Clirr, so I'd feel happier achieving this in the
verify phase using clirr:check. It is a hazy line between enforcer
rules and other plugin goals, but I'd suggest using rules for (fast)
environment and POM checks and other plugins for (slower) checks that
require results of lifecycle phases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
No worries. I just thought it might garner more notice and more usage if it
went out in the 1.0. Giving the rule a more powerful sense of credibility
than it might otherwise have. Just thinking of some of the managers and
architects i've been selling maven to over the past few years.
On Nov 4, 2010 4:26 PM, "Brian Fox" <br...@infinity.nu> wrote:
Nah, i'll just release it again.
On Thu, Nov 4, 2010 at 2:31 PM, Rex Hoffman <re...@e-hoffman.org> wrote:
> On Thu, Nov 4, 2010 at 11:...
Re: Auto apache version standard as an enforcer rule?
Posted by Brian Fox <br...@infinity.nu>.
Nah, i'll just release it again.
On Thu, Nov 4, 2010 at 2:31 PM, Rex Hoffman <re...@e-hoffman.org> wrote:
> On Thu, Nov 4, 2010 at 11:28 AM, Rex Hoffman <re...@e-hoffman.org> wrote:
>
>> Seems reasonable, build a helper library to run clirr and analyze it's
>> results, allow the clirr plugin to use it in it's existing manner, or by an
>> enforcer rule.
>>
>> That fact that it's clirr under the hood of that enforcer rule will be
>> completely abstracted. This will be a rule to enforce apache version
>> standard, that happens to use clirr. I'll write a clean api for it's
>> analysis provider (clirr).
>>
>> I know it'll be annoying, that's kinda the point. If your working on a
>> 1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
>> The rule will tell the dev to correct the method, or bump the version
>> number to 2.0-SNAPSHOT. The real danger is a dev not being aware that they
>> have produced a backwards breaking change. Again, very helpful for apis.
>>
>> Given Brett's email today citing the desire for
>>
>> "
>> Configurable conflict resolution strategy - newest, oldest that satisfies
>> Enforcer rule to lock down above
>> Importance of specificity, not magic - break the build if conflicting
>> versions, not try and solve it
>> Be deterministic is maven's strength
>> "
>>
>> I think it's important we codify how maven wants devs to think about
>> versions. Right now it a snapshot or release. The ranges have vague
>> meaning at best, not knowing what version policy the project you depend on
>> follows.
>>
>>
> "Hold off on the release" that is.... only one typo in this message, I can
> live with that....
>
>
>> If you want to hold of the release until Monday, I will commit to having it
>> done and tested by then??
>>
>> I think having the dependency-convergence rule and this rule will do a lot
>> for many organization that have or are adopting maven. I know it definitely
>> helped at the last place I worked.
>>
>> Rex
>>
>> On Thu, Nov 4, 2010 at 11:12 AM, Brian Fox <br...@infinity.nu> wrote:
>>
>>> > If I were to clean this up and construct an enforcer rule that
>>> > demanded adherence to the letter of the law of the apache version
>>> > standard, is something that would be allowed into the maven enforcer
>>> > plugin?
>>> >
>>>
>>> Given a proper rule with tests, I would unlikely reject it out of hand.
>>>
>>> > Or would the team prefer I continue to try to work the the clirr-mojo?
>>> >
>>>
>>> My gut though is that this might be better as a report than a rule. I
>>> think an enforcer rule could get in the way of developers if as soon
>>> as they made a breaking change, the build blew up on them. It would
>>> make a bit more sense in a release profile but even there blowing up a
>>> build is annoying.
>>>
>>> What belongs in the enforcer vs other plugins is definitely a grey
>>> area that has no great answer. Certainly I could make a rule to
>>> duplicate checkstyle and pmd checks, but those plugins have ways of
>>> failing the build already. The enforcer wasn't intended to become the
>>> central place for all things that fail a build, although it could.
>>>
>>> Given that there seems to be great overlap with the clirr stuff in
>>> checking the api, it feels like the functionality should be there.
>>> However, if you construct it as a separate plexus component, then both
>>> clirr and the enforcer could use that shared code to provide multiple
>>> ways to attack it.
>>>
>>> > Give me a firm commitment (contingent on quality of course ) and I
>>> > could have this done tonight.
>>> >
>>> > Rex
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>>
>>
>>
>> --
>> Rex
>> (415) 273-9438
>> http://www.e-hoffman.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
On Thu, Nov 4, 2010 at 11:28 AM, Rex Hoffman <re...@e-hoffman.org> wrote:
> Seems reasonable, build a helper library to run clirr and analyze it's
> results, allow the clirr plugin to use it in it's existing manner, or by an
> enforcer rule.
>
> That fact that it's clirr under the hood of that enforcer rule will be
> completely abstracted. This will be a rule to enforce apache version
> standard, that happens to use clirr. I'll write a clean api for it's
> analysis provider (clirr).
>
> I know it'll be annoying, that's kinda the point. If your working on a
> 1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
> The rule will tell the dev to correct the method, or bump the version
> number to 2.0-SNAPSHOT. The real danger is a dev not being aware that they
> have produced a backwards breaking change. Again, very helpful for apis.
>
> Given Brett's email today citing the desire for
>
> "
> Configurable conflict resolution strategy - newest, oldest that satisfies
> Enforcer rule to lock down above
> Importance of specificity, not magic - break the build if conflicting
> versions, not try and solve it
> Be deterministic is maven's strength
> "
>
> I think it's important we codify how maven wants devs to think about
> versions. Right now it a snapshot or release. The ranges have vague
> meaning at best, not knowing what version policy the project you depend on
> follows.
>
>
"Hold off on the release" that is.... only one typo in this message, I can
live with that....
> If you want to hold of the release until Monday, I will commit to having it
> done and tested by then??
>
> I think having the dependency-convergence rule and this rule will do a lot
> for many organization that have or are adopting maven. I know it definitely
> helped at the last place I worked.
>
> Rex
>
> On Thu, Nov 4, 2010 at 11:12 AM, Brian Fox <br...@infinity.nu> wrote:
>
>> > If I were to clean this up and construct an enforcer rule that
>> > demanded adherence to the letter of the law of the apache version
>> > standard, is something that would be allowed into the maven enforcer
>> > plugin?
>> >
>>
>> Given a proper rule with tests, I would unlikely reject it out of hand.
>>
>> > Or would the team prefer I continue to try to work the the clirr-mojo?
>> >
>>
>> My gut though is that this might be better as a report than a rule. I
>> think an enforcer rule could get in the way of developers if as soon
>> as they made a breaking change, the build blew up on them. It would
>> make a bit more sense in a release profile but even there blowing up a
>> build is annoying.
>>
>> What belongs in the enforcer vs other plugins is definitely a grey
>> area that has no great answer. Certainly I could make a rule to
>> duplicate checkstyle and pmd checks, but those plugins have ways of
>> failing the build already. The enforcer wasn't intended to become the
>> central place for all things that fail a build, although it could.
>>
>> Given that there seems to be great overlap with the clirr stuff in
>> checking the api, it feels like the functionality should be there.
>> However, if you construct it as a separate plexus component, then both
>> clirr and the enforcer could use that shared code to provide multiple
>> ways to attack it.
>>
>> > Give me a firm commitment (contingent on quality of course ) and I
>> > could have this done tonight.
>> >
>> > Rex
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>
>
> --
> Rex
> (415) 273-9438
> http://www.e-hoffman.org
>
>
Re: Auto apache version standard as an enforcer rule?
Posted by Rex Hoffman <re...@e-hoffman.org>.
Seems reasonable, build a helper library to run clirr and analyze it's
results, allow the clirr plugin to use it in it's existing manner, or by an
enforcer rule.
That fact that it's clirr under the hood of that enforcer rule will be
completely abstracted. This will be a rule to enforce apache version
standard, that happens to use clirr. I'll write a clean api for it's
analysis provider (clirr).
I know it'll be annoying, that's kinda the point. If your working on a
1.1-SNAPSHOT and create a backwards breaking change, you have messed up.
The rule will tell the dev to correct the method, or bump the version
number to 2.0-SNAPSHOT. The real danger is a dev not being aware that they
have produced a backwards breaking change. Again, very helpful for apis.
Given Brett's email today citing the desire for
"
Configurable conflict resolution strategy - newest, oldest that satisfies
Enforcer rule to lock down above
Importance of specificity, not magic - break the build if conflicting
versions, not try and solve it
Be deterministic is maven's strength
"
I think it's important we codify how maven wants devs to think about
versions. Right now it a snapshot or release. The ranges have vague
meaning at best, not knowing what version policy the project you depend on
follows.
If you want to hold of the release until Monday, I will commit to having it
done and tested by then??
I think having the dependency-convergence rule and this rule will do a lot
for many organization that have or are adopting maven. I know it definitely
helped at the last place I worked.
Rex
On Thu, Nov 4, 2010 at 11:12 AM, Brian Fox <br...@infinity.nu> wrote:
> > If I were to clean this up and construct an enforcer rule that
> > demanded adherence to the letter of the law of the apache version
> > standard, is something that would be allowed into the maven enforcer
> > plugin?
> >
>
> Given a proper rule with tests, I would unlikely reject it out of hand.
>
> > Or would the team prefer I continue to try to work the the clirr-mojo?
> >
>
> My gut though is that this might be better as a report than a rule. I
> think an enforcer rule could get in the way of developers if as soon
> as they made a breaking change, the build blew up on them. It would
> make a bit more sense in a release profile but even there blowing up a
> build is annoying.
>
> What belongs in the enforcer vs other plugins is definitely a grey
> area that has no great answer. Certainly I could make a rule to
> duplicate checkstyle and pmd checks, but those plugins have ways of
> failing the build already. The enforcer wasn't intended to become the
> central place for all things that fail a build, although it could.
>
> Given that there seems to be great overlap with the clirr stuff in
> checking the api, it feels like the functionality should be there.
> However, if you construct it as a separate plexus component, then both
> clirr and the enforcer could use that shared code to provide multiple
> ways to attack it.
>
> > Give me a firm commitment (contingent on quality of course ) and I
> > could have this done tonight.
> >
> > Rex
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Rex
(415) 273-9438
http://www.e-hoffman.org
Re: Auto apache version standard as an enforcer rule?
Posted by Brian Fox <br...@infinity.nu>.
> If I were to clean this up and construct an enforcer rule that
> demanded adherence to the letter of the law of the apache version
> standard, is something that would be allowed into the maven enforcer
> plugin?
>
Given a proper rule with tests, I would unlikely reject it out of hand.
> Or would the team prefer I continue to try to work the the clirr-mojo?
>
My gut though is that this might be better as a report than a rule. I
think an enforcer rule could get in the way of developers if as soon
as they made a breaking change, the build blew up on them. It would
make a bit more sense in a release profile but even there blowing up a
build is annoying.
What belongs in the enforcer vs other plugins is definitely a grey
area that has no great answer. Certainly I could make a rule to
duplicate checkstyle and pmd checks, but those plugins have ways of
failing the build already. The enforcer wasn't intended to become the
central place for all things that fail a build, although it could.
Given that there seems to be great overlap with the clirr stuff in
checking the api, it feels like the functionality should be there.
However, if you construct it as a separate plexus component, then both
clirr and the enforcer could use that shared code to provide multiple
ways to attack it.
> Give me a firm commitment (contingent on quality of course ) and I
> could have this done tonight.
>
> Rex
>
> ---------------------------------------------------------------------
> 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