You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Lennart Jorelid <lj...@jguru.se> on 2010/11/12 14:57:14 UTC
Use of standards in the Maven core
Hello all,
I must confess I appreciate standards in larger projects.
Unless there are solid technology-based reasons not to use
existing standards, I say we should strive to use standards
as often as we can. If we do, we can acquire better
feedback and more informed suggestions for improvement.
We use quite a few nonstandard patterns and components within
the Maven3 core - so let me suggest some refactoring ideas,
which I believe will simplify and augment Maven's internals
in upcoming releases.
Model improvements:
a) Xpp3 --> JAXB.
We use Xpp3 to move entities to/from XML.
The JSE standard is JAXB which could generate both
XML and XSD documents for all our projects.
We need only add JAXB annotations to our classes
and properties for it to happen. If we feel that
the model becomes bogged down in annotations, we
can simply create our own compound annotations
to reduce clutter.
b) .mdo --> .java.
We use Modello to generate large portions of the
mainly static central parts of Maven. I believe we
would do better without generated code within the
Maven distribution, for 3 reasons:
1) Java is simple to read, understand and refactor.
XML source files - such as Modello's - are neither.
For that reason alone, we should contemplate removing
a code generation tool. Moreover, to properly handle
changes in the Maven model, one needs to understand
Modello. This increases the time required to get started
in committing patches and ideas to the Maven core/model.
2) The Maven model is largely stable, so code generation
shouldn't really be needed. It's easier just to remove
the code generation and commit well-written Java code.
3) Generated code tends to contain quite a number of
no-op setters/getters (i.e. bloat), take poor use of
OO constructs such as inheritance (we generate no
abstract classes with common/template methods for use
in several subclasses) and provide somewhat poor javadoc.
This discussion can be exemplified with the setter below,
which provides no parameter validation
(i.e. "no-op setter antipattern"), not quite a sensible
JavaDoc and no explanation of its parameter's significance.
While I believe that most of us will eventually understand
what goes on here, I suggest that overall code quality is
reduced by the generation tool. Let's move to a Java model.
/**
* Set specifies that this profile will be activated when
* matching operating system
* attributes are detected.
*
* @param os
*/
public void setOs( ActivationOS os )
{
this.os = os;
} //-- void setOs( ActivationOS )
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Brett Porter <br...@apache.org>.
On 13/11/2010, at 12:57 AM, Lennart Jorelid wrote:
> Hello all,
>
> I must confess I appreciate standards in larger projects.
> Unless there are solid technology-based reasons not to use
> existing standards, I say we should strive to use standards
> as often as we can. If we do, we can acquire better
> feedback and more informed suggestions for improvement.
>
> We use quite a few nonstandard patterns and components within
> the Maven3 core - so let me suggest some refactoring ideas,
> which I believe will simplify and augment Maven's internals
> in upcoming releases.
>
> Model improvements:
> a) Xpp3 --> JAXB.
> We use Xpp3 to move entities to/from XML.
This isn't quite the right comparison. Xpp3 is a pull parser, a precursor to StAX. There was this issue to migrate: http://jira.codehaus.org/browse/MNG-2255. However I have a feeling it was undone in the process of Maven 3 dev't. This is still worth doing IMO, though as Nicolas says we need to keep the old API around since plugins depend on it.
>
>
> b) .mdo --> .java.
> We use Modello to generate large portions of the
> mainly static central parts of Maven. I believe we
> would do better without generated code within the
> Maven distribution, for 3 reasons:
>
> 1) Java is simple to read, understand and refactor.
> XML source files - such as Modello's - are neither.
> For that reason alone, we should contemplate removing
> a code generation tool. Moreover, to properly handle
> changes in the Maven model, one needs to understand
> Modello. This increases the time required to get started
> in committing patches and ideas to the Maven core/model.
>
> 2) The Maven model is largely stable, so code generation
> shouldn't really be needed. It's easier just to remove
> the code generation and commit well-written Java code.
This also somewhat negates against your 1st point :)
>
> 3) Generated code tends to contain quite a number of
> no-op setters/getters (i.e. bloat), take poor use of
> OO constructs such as inheritance (we generate no
> abstract classes with common/template methods for use
> in several subclasses) and provide somewhat poor javadoc.
I assume you mean here to use JAXB instead, rather than maintaining a hand generated parser/writer?
I don't disagree for a new project. It might be worth trying now that we support Java 5 and have a wider set of tests.
That said, to date, I think the reason it hasn't been tried is that it's unlikely to provide substantial value relative to the work involved. It is working fine at the moment and rarely requires modification. You'd need to check not only that the behaviour and performance matches, but that the generated XPP3 reader/writer can be mapped to the new code and still work within plugins, etc. At the same time, you're adding new dependencies that previously weren't required (unless we start requiring Java 6...).
I'm not sure it's worth it, even aside from the debate of the merits of using JAXB vs. code generation.
This would all be more relevant to discuss in the context of changing the way the POM & metadata are handled (a discussion I'm yet to catch up on unfortunately). If that demands some changes to the way we are processing them that these could help with it would make more sense.
My $A0.02...
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Lennart Jörelid <le...@gmail.com>.
First - sorry about the time it took for me to produce this answer.
Things are hectic in Scandinavia for certain.
:)
All right - here we go.
2010/11/18 Kristian Rosenvold <kr...@gmail.com>
[znip]
> As for the patterns discussion nothing specific is being said, so I'm
> eagerly anticipating specifics.
>
>
I got half an hour this weekend, so did some dissection of the first class
one encounters
within the Maven model project. That happens to be the Activation class, and
found some things
I would suggest refactoring. I'll present them in the form Symptom, Remedy,
Example.
For the discussion below, exact semantics are not quite important - the code
quality and
potential for refactoring is.
*Current antipatterns and remedies*
a) *Symptom:* Lots of empty entity setters/getters (i.e. bloat). If getters
and setters do not provide any
validation, annotation placeholding or type conversion, they do not
really provide any value.
(No proper information hiding if the setter/getter simply access the
property).
Instead, empty setters/getters confuse the reader and yield more
maintenance time/cost/pain than if
they simply did not exist in the code base.
*Remedy:* Replace empty JavaBean property methods with public access to
members.
*Example (JavaDoc deleted for brevity): *
Current Pattern
===========
private String jdk;
public String getJdk() {
return this.jdk;
}
public void setJdk( String jdk ) {
this.jdk = jdk;
}
Recommended Pattern
=================
public String jdk;
b) *Symptom:* Lacklustre Separation of Concern and Lack of Object oriented
structure.
Entities/model holds not only state, but also methods/properties dealing
with location within the pom/XML configuration file.
Moreover, these methods and properties are copied within all Maven's
model entities (as opposed to
being placed within an abstract superclass or commonly used, factored-out
delegate).
*Remedy:* Refactor the model to introduce abstract superclasses or delegate
types holding functionality
dealing with configuration file tracking and/or integration to the
Lifecycle.
Place only model state within the entity classes.
*Example (JavaDoc deleted for brevity):*
**Current Pattern (in most entities)
==================================
private java.util.Map<Object, InputLocation> locations;
public void setLocation( Object key, InputLocation location )
{
if ( location != null )
{
if ( this.locations == null )
{
this.locations = new java.util.LinkedHashMap<Object,
InputLocation>();
}
this.locations.put( key, location );
}
}
public InputLocation getLocation( Object key )
{
return ( locations != null ) ? locations.get( key ) : null;
}
Recommended Pattern
===================
public class SomeEntity extends AbstractEntity
{
// Only domain properties here
// No framework utility methods or properties.
// They could/should be placed within superclasses.
}
public abstract class AbstractEntity implements LocationAware
{
// Deal with hashCode(), equals(), clone() and the like here.
// Use reflection, to handle subclass needs.
// Also, implement the LocationAware interface here, to
// provide required integration with the configuration
// framework.
}
public interface LocationAware
{
// Define the integration API to the configuration FW here.
}
c) *Symptom:* Metadata strewn around in model, in the form of properties and
methods.
This is a matter of style, but I advocate that we separate domain
properties (i.e.
the properties within domain classes) from metadata which could/should be
represented
as annotations.
*Remedy:* Separate out metadata, such as configuration representation into
annotations,
to reduce the potential for data/metadata confusion. Examples of such
metadata could
be the precise format for configuration file storage. Also, we could get
rid of
unnecessary constrained criteria and properties, that could be replaced
with common
types and - optionally - metadata. Provide extensible structures, such as
typed
collections instead of specific properties (this appears to be something
of a syndrome
in the Activation class, but is likely similar in other places).
*Example (JavaDoc deleted for brevity):*
**Current Pattern
===============
<All of the classes within the .io package [throughout Maven core]>
<Lots of Plexus dependencies, such as>
import org.codehaus.plexus.util.ReaderFactory;
import org.codehaus.plexus.util.xml.Xpp3DomBuilder;
import org.codehaus.plexus.util.xml.pull.MXParser;
import org.codehaus.plexus.util.xml.pull.XmlPullParser;
import org.codehaus.plexus.util.xml.pull.XmlPullParserException;
Recommended Pattern
===================
<remove .io packages + their content>
Remove dependencies on Plexus as per above, et. al.
Introduce metadata to represent configuration file structure, such as the
standard JAXB annotations.
*@XmlType(namespace = "http://maven.apache.org/model/nazgul")*
*@XmlAccessorType(XmlAccessType.FIELD)*
@SuppressWarnings("all")
public class Activation extends AbstractEntity implements Serializable
{
...
/**
* List holding all ActivationCriteria of this Activation block.
* ActivationCriterion instances will be checked in the order
* they were read from the configuration (i.e. the same order
* with which they occur within this List).
*/
*@XmlElementWrapper(name = "criteria", nillable = false, required =
true)*
* @XmlElements({*
* @XmlElement(name = "jdkCriterion", type =
JdkActivationCriterion.class, required = false),*
* @XmlElement(name = "osCriterion", type =
OsActivationCriterion.class, required = false),*
* @XmlElement(name = "propertyCriterion", type =
PropertyActivationCriterion.class, required = false),*
* @XmlElement(name = "fileCriterion", type =
FileActivationCriterion.class, required = false)*
* })*
* public List<ActivationCriterion> criteria = new
ArrayList<ActivationCriterion>();*
...
d) *Symptom:* Identical documentation strewn on property, setter and getter.
Along the
same lines of reasoning as in (a) above, this is simply confusing.
I would recommend against copy/paste-programming.
*Remedy:* Fixed when removing unnecessary setters/getters, as per (a) above.
*Example (JavaDoc deleted for brevity): *See (a) above.
*Concluding example for the Activation class:*
This is simply an example of how we could refactor the maven domain,
to reduce its footprint, and - hopefully - facilitate understanding.
Feel free to compare this incarnation of Activation class with the
current one, and comment on the simplicity and clarity.
I feel there is quite a lot of places where similar simplifications
can be done within the maven model and core.
... and I'll be back with more code and thoughts later on.
package org.apache.maven.model;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlType;
import java.io.Serializable;
/**
* The conditions within the build runtime environment which will
* trigger the automatic inclusion of the build profile.
*/
@XmlType(namespace = "http://maven.apache.org/model/nazgul")
@XmlAccessorType(XmlAccessType.FIELD)
@SuppressWarnings("all")
public class Activation extends AbstractEntity implements Serializable
{
/**
* If set to <code>true</code>, this profile will be active unless
another
* profile in this pom is activated using the command line -P
* option or by one of that profile's activators.
*/
@XmlAttribute
public boolean activeByDefault = false;
/**
* List holding all ActivationCriteria of this Activation block.
* ActivationCriterion instances will be checked in the order
* they were read from the configuration (i.e. the same order
* with which they occur within this List).
*/
@XmlElementWrapper(name = "criteria", nillable = false, required = true)
@XmlElements({
@XmlElement(name = "jdkCriterion", type =
JdkActivationCriterion.class, required = false),
@XmlElement(name = "osCriterion", type =
OsActivationCriterion.class, required = false),
@XmlElement(name = "propertyCriterion", type =
PropertyActivationCriterion.class, required = false),
@XmlElement(name = "fileCriterion", type =
FileActivationCriterion.class, required = false)
})
public List<ActivationCriterion> criteria = new
ArrayList<ActivationCriterion>();
}
--
--
Lennart Jörelid
Re: Use of standards in the Maven core
Posted by Kristian Rosenvold <kr...@gmail.com>.
I am wondering about what kind of documentation you are thinking about.
We have so much documentation that I hardly know where to stop.
I think "blind" javadoc is just so much baloney. If there are any
specific use cases that require documentation I'm happy to discuss
that.
Kristian
ti., 27.09.2011 kl. 09.24 -0400, skrev Mark H. Wood:
> On Tue, Sep 27, 2011 at 07:49:37AM -0400, Jesse Glick wrote:
> > On 11/19/2010 02:19 PM, Kristian Rosenvold wrote:
> > > if it hurts you, make a patch; documentation upgrade, javadoc or code changes
> >
> > The difficulty with submitting Javadoc changes is that if you need
> > the Javadoc you probably are not going to be sure what it should
> > say. :-)
>
> I am always amused (and saddened) to read that the documentation
> should be written by those who do not understand the code.
>
> It is possible to do this tolerably well. It's exhausting, but it
> *is* an effective way to get to know the product better --
> eventually. And there are still gaps: places where it's simply not
> feasible to divine what the author was thinking when he wrote *that*.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, Sep 27, 2011 at 07:49:37AM -0400, Jesse Glick wrote:
> On 11/19/2010 02:19 PM, Kristian Rosenvold wrote:
> > if it hurts you, make a patch; documentation upgrade, javadoc or code changes
>
> The difficulty with submitting Javadoc changes is that if you need
> the Javadoc you probably are not going to be sure what it should
> say. :-)
I am always amused (and saddened) to read that the documentation
should be written by those who do not understand the code.
It is possible to do this tolerably well. It's exhausting, but it
*is* an effective way to get to know the product better --
eventually. And there are still gaps: places where it's simply not
feasible to divine what the author was thinking when he wrote *that*.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
Re: Use of standards in the Maven core
Posted by Jesse Glick <je...@oracle.com>.
Reposting to an old thread, since I am still running into what seems to be Maven 2 debris in the APIs.
On 11/19/2010 02:19 PM, Kristian Rosenvold wrote:
> if it hurts you, make a patch; documentation upgrade, javadoc or code changes
The difficulty with submitting Javadoc changes is that if you need the Javadoc you probably are not going to be sure what it should say. :-) I considered submitting a
pull request to github.com/apache/maven-3 basically documenting org.apache.maven.artifact.resolver.ArtifactResolutionRequest.setMirrors to say "do not trust that I do
anything", but it is not obvious under which circumstances it actually does what it sounds like. A little story:
I had a call to org.apache.maven.repository.RepositorySystem.resolve. Undocumented, but it seems to download artifacts to the local repository (when not already present),
a generally useful task. (While the interface is in Maven Core, the only impl is in Maven Compat and named - ominously - LegacyRepositorySystem. If it is supposed to be
deprecated, there is no Javadoc saying so, or suggesting a replacement, so I stick with it for now.)
However yesterday I noticed that it was not working on an artifact in Central that I knew existed and in fact was very likely cached in my local Nexus. For reasons
irrelevant here the remoteRepositories in the call included a definition of Central as http://central/ (taken from Nexus installation FAQs), but the actual URL should not
have mattered since I have a mirror definition. Therefore my local mirror settings were being ignored.
Taking a look at the call to resolve, it is given an ArtifactResolutionRequest. I had a org.apache.maven.settings.Settings object handy with the right mirror definitions,
so code completion and common sense would dictate that I should call request.setMirrors(settings.getMirrors())... but this had no effect.
Time for the debugger. I set the mirrors on the request and follow what happens. The list of mirrors is read in org.apache.maven.artifact.resolver.DefaultArtifactResolver
but this line of code is never encountered. Instead, when request.isResolveRoot() returns true - the default value - an attempt is made to download the artifact _before_
considering the mirrors, which in this case fails and returns early from the resolve method. I could try to not "resolve the root", whatever that means (no Javadoc), but
this just looks wrong. Anyway even if the request is not "resolving the root", the mirrors are considered only if the request also isResolveTransitively(), which I do not
want in general.
So I set a breakpoint on org.apache.maven.artifact.resolver.ArtifactResolutionException. This gets thrown from another overload of "resolve" as a result of a
org.sonatype.aether.resolution.ArtifactResolutionException, so set a breakpoint on that. This is thrown from org.sonatype.aether.impl.internal.DefaultArtifactResolver
(now you see why I am giving fully-qualified class names), apparently due to a org.sonatype.aether.transfer.ArtifactTransferException which seems like the expected
low-level error. When it gets thrown there is no sign of the mirrors, just http://central/; but local variables include a org.sonatype.aether.RepositorySystemSession
which has a NullMirrorSelector, which must be wrong.
Presumably something was supposed to call org.sonatype.aether.util.DefaultRepositorySystemSession.setMirrorSelector; nothing in the call stack does so. So who calls this
with a nontrivial selector? org.apache.maven.DefaultMaven.newRepositorySession does, and shows how it can be used. But where do I get that session? From prior experience
I knew that org.apache.maven.plugin.LegacySupport.setSession is needed for many calls from Maven Compat. And indeed, http://hg.netbeans.org/main-silver/rev/9d464b81555e
makes the mirror settings be honored, basically passing them in thread-local state.
So what is the upshot? Maybe org.apache.maven.repository.RepositorySystem.resolve needed to be deprecated to begin with. (Replaced perhaps by
org.sonatype.aether.RepositorySystem.resolveArtifact?) It is used in one place in Maven Core - which, incidentally, does call request.setMirrors, but also
setResolveRoot(false) and setResolveTransitively(true) and so conveniently triggering the conditions for the mirrors to be read! But this is in
DefaultProjectDependenciesResolver, and ProjectDependenciesResolver is never called - while again in Core and not deprecated, meaning the mold may be deeper in the cheese.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Kristian Rosenvold <kr...@gmail.com>.
fr., 19.11.2010 kl. 12.12 -0500, skrev Jesse Glick:
>So I think the issue is that older code never got fully documented or
>made foolproof, which is understandable given the focus on shipping
>3.0.
As usual it's about scratching an itch, this is open source. So if it
hurts you, make a patch; documentation upgrade, javadoc or code changes;
we'll look at it! Starting small is a good idea, replacing xpp3 as a
first submission is probably not a good idea ;)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Jesse Glick <je...@oracle.com>.
On 11/18/2010 03:34 AM, Kristian Rosenvold wrote:
> The rant is somewhat about seeing all these internal components.
A little bit, though it is generally easy to see from the package or class name that something should be considered an implementation. My slow learning curve has had to
do with the interfaces, probably not helped by starting from embedder code originally written against Maven 2 that was probably doing things the wrong way.
I should note that what I have seen so far of Aether interfaces has been much more clearly documented, and the code looks to do a better job of noticing invalid or
missing parameters and throwing helpful exceptions early. So I think the issue is that older code never got fully documented or made foolproof, which is understandable
given the focus on shipping 3.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Kristian Rosenvold <kr...@gmail.com>.
Den 18.11.2010 08:32, skrev Lennart Jörelid:
> [bit of rather funny rant/read znipped out]
>
I think the rant was a real good description of why/how working with
open source is fun ;)
Maven 3 must be regarded in the proper context to understand what
happened. At the implementation level
some former 1400-line classes with 500 line long methods were split into
smaller (testable) components, most
are still in the "internal" namespaces and clearly marked as not public.
And I think this is
one of the real problems that we might want to take a shot at; making
private implementation stuff stay private.
The rant is somewhat about seeing all these internal components. The
intention of these internal componens
was never to cast this design in stone either; the granulation/division
of labour in these components is mostly
there to facilitate easier future change.
As for the patterns discussion nothing specific is being said, so I'm
eagerly anticipating specifics.
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Use of standards in the Maven core
Posted by Lennart Jörelid <le...@gmail.com>.
Hello all,
On 11/15/2010 04:27 AM, Brett Porter wrote:
[znip]
> > We use quite a few nonstandard patterns and components within
> the Maven3 core - so let me suggest some refactoring ideas,
> which I believe will simplify and augment Maven's internals
> in upcoming releases.
>
> Model improvements:
> a) Xpp3 --> JAXB.
> We use Xpp3 to move entities to/from XML.
> This isn't quite the right comparison. Xpp3 is a pull parser, a precursor
> to
StAX. There was this issue to migrate:
http://jira.codehaus.org/browse/MNG-2255. However I have a feeling it was
undone in the process of Maven 3 dev't. This is still worth doing IMO,
> though
as Nicolas says we need to keep the old API around since plugins depend on
> it.
I realise that we base our POJO --> XML --> POJO conversions on the Xpp3
pull parser, and that it has more in common with StAX than JAXB.
However, my point is more that JAXB's framework performs the same
function, while also being the JSE standard for
Serialization/Deserialization
of POJOs to XML. This implies more people know how to handle themselves
gracefully around JAXB... which is good for bugfixing and idea spawning.
Since I believe we have a few simplifications to do WRT the Maven core in
general, I wanted to toss the idea to the list as an appetizer; I'm well
aware of
the workload required to move to the JSE standard. However, I think we
should
consider moving in the general direction of using JSE standards in most or
all
parts of the Maven core. We need to facilitate understanding
and increase code quality.
2010/11/16 Jesse Glick <je...@oracle.com>
>
>
> On a tangent, I agree with Lennart's complaints about the quality of the
> interfaces generated by Modello, but at least I can refer
back to the schema for explanation; the hand-written interfaces in Maven are
> just as bad as regards null safety, bean "pattern"
abuse, and Javadoc, but in a less predictable way. My experiences embedding
> Maven 3 in an IDE go something like this:
[bit of rather funny rant/read znipped out]
All right ... I believe we have a problem with opaqueness / lack of
transparency in the Maven core.
It would appear we have a few rather evident issues that we would need to
handle sooner, rather than later.
Let me make a few suggestions here:
a) *Suggestion:* perscribe / use / enforce some rudimentary design patterns
for the Maven core.
*Purpose:* increase code quality, facilitate understanding
*Benefit:* increase the informed developer base to increase improvement
influx to the project. We simply need more folks who cares enough to make
improvement suggestions and patches. Some parts of the core certainly could
use some TLC.
I'll take a shot at some initial design patterns in a following posting to
the list.
Everyone are encouraged to provide suggestions before or after mine hit the
list.
b) *Suggestion:* Refactor the Plugin structure, simplify plugin testing,
provide more specific Abstract plugin classes that encapsulate common
problems.
*Purpose:* Increase development pace and quality of plugin development.
*Benefit:* Reduce the number of unmaintained plugins. Reduce the barrier to
develop and maintain plugins. Increase quality of plugins.
I have developed a number of plugins for quite a few projects lately.
Each of these projects have developed their own custom plugin framework with
inhouse abstract classes and testing frameworks... since the plugin
framework and testing structure provided by in Maven has proven inadequate
or overly complex for some reason.
I'll take a shot at suggesting improvements in an upcoming posting to the
list.
Everyone are encouraged to provide suggestions before or after mine hit the
list.
--
Best regards,
Lennart Jörelid
Re: Use of standards in the Maven core
Posted by Jesse Glick <je...@oracle.com>.
On 11/15/2010 04:45 AM, nicolas de loof wrote:
> AFAIK most code (including some
> plugins) related to POM parsing use Xpp3Reader, as we don't provide an
> abstraction API for POM parsing.
Along the same lines, http://jira.codehaus.org/browse/MNG-4862 shows that org.apache.maven.model.ConfigurationContainer assumes that unspecified XML trees are represented
as Xpp3Dom, so any code which e.g. reads/writes a plugin's <configuration> must cast to Xpp3Dom and use this interface. I doubt it would be straightforward to introduce a
compatibility layer now, other than a supertype in the Maven namespace with a similar signature as Xpp3Dom, which would not really simplify usage.
On a tangent, I agree with Lennart's complaints about the quality of the interfaces generated by Modello, but at least I can refer back to the schema for explanation; the
hand-written interfaces in Maven are just as bad as regards null safety, bean "pattern" abuse, and Javadoc, but in a less predictable way. My experiences embedding Maven
3 in an IDE go something like this:
1. Look around the class index for something that sounds vaguely like what you need. If there is a ProjectLifecycleArtifactDependencyResolver interface and a
DependencyArtifactProjectScopeResolver and a LifecycleScopeArtifactDependencyClassifier etc. etc. then just pick one. Any Javadoc would anyway be of the form "This is an
artifact dependency resolver for the project lifecycle", which doesn't tell you anything about who uses it, when, or why. If it's @Deprecated, perhaps it came from Maven
2; pick another one randomly, since the Javadoc never says what the intended replacement is.
2. Check source code backreferences to see if the interface you picked is ever actually called. If not, return to step 1.
3. Hope that there is an instance of the interface somewhere in the Plexus container. (And that no special role hint is needed, since these are unlikely to be documented
anyway.) Check class index for DefaultEtcEtc, and read source code to see if it sounds like it is doing something you wanted.
4. Grab an instance and try calling some method on it. Usually there will be five overloads so just pick the one with the shortest argument list.
5. Take the first NullPointerException you encounter and inspect the code mentioned in the stack frames. Use a process of logical inference to determine what field of
what class was expected to be non-null. This is sometimes complicated by the presence of several different SomethingRequest interfaces being passed around and
interconverted, each of which has its own (undocumented) assumptions about nullity of certain parameters - and conversion is always of the form
newRequest.setFrobnitz(oldRequest.getFrobnitz()) with no intermediate sanity check.
6. Call the setter corresponding to the null field in #5 and return to step 4 until something happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
AW: Use of standards in the Maven core
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
Not beening a maven developer, just a maven-newbi, but modelling with UML was pushed very high some days.
UML then RUP to use UML, then based on UML specs some CASE Tools, developed, and then we started to learn to express our demands by using a graphical notation language, AND without the need to undestand how this graphical notation is keep on store, we generate code, Java, C++ etc. just to mention two examples.
Dependencies are expressed as graphical notations oall over in UML. Maven-projects are full of dependencies?
Wouldn't it be nice to have a CASE Tool to show use dependecies; I know NetBeans can show dependencies. And others too. But how can I modify my dependecies using a graphical notation?How good are UML CASE Tools in modelling artefacts for maven? How good are the integrated with maven?
When I look briefly at modello xml's, I have no intention to learn how to hand write such modello model xml code/text. For me this is like learnig Thai, like learning a next language (I speak Germa English French and Spain and master quite a few programming languages, so why shall I learn a next one if we can avoid it?).
If you give me the proper modelo model xml code generator integrated into my NB UML CASE Tool, why shall I then need to learn modello model xml language?
And if round trip engineering is in place, that may help to a) get FAST an idea about my maven core model/architecture (a because a picture tells you more then thousand words) and b) allows me to make my changes on the graphical level and generate modello model xml files to then be processed, parsed, and process as wanted. Generating code for maven core is just one example.
What I want to ask is:
Are you using UML or any other CASE tools today to generate modello model files for maven-core?
Would that approach eventually make sense to be used to generate other maven-artifacts too, to be used from the amazing maven tool-suite, the maven-plugins?
What about round trip engineering, UML - maven-artefacts - code - maven-artefacts - UML?
Are we approching a more model oriented world expressed by graphical notations like UML, where a graphic tells you much more then 1000 lines of code/text, whether it is hand writen or generated code/text or xml?
OR are we just on the top of the modelling-land and do we now go down-again from this top where we come from, from the wild-hand-coding-land?
Standardising should be based on over-view, should be based on architectures, not tools. In this context Xpp3Reader/Writer and JAXB are just tools. How to they help to make a complex world less complex by giving me an overview?
I think we have the CASE tools to day. Now we should integrate them properly with the marvelous maven world. And what would be a better example as when a developers team, developing maven, uses UML artefacts and code generation regardless if modello model xml files are considered an intermediat step to get maven-core working.
Josef
-----Ursprüngliche Nachricht-----
Von: nicolas de loof [mailto:nicolas.deloof@gmail.com]
Gesendet: Montag, 15. November 2010 10:46
An: Maven Developers List
Betreff: Re: Use of standards in the Maven core
I may be wrong regarding maven3-core, but AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing. Such a migration to JAXB (or other),
without consideration to the technical beneficts, would require a
compatibility layer. Can we provide some Xpp3-compliant API on top of JAXB ?
2010/11/12 Lennart Jorelid <lj...@jguru.se>
> Hello all,
>
> I must confess I appreciate standards in larger projects.
> Unless there are solid technology-based reasons not to use
> existing standards, I say we should strive to use standards
> as often as we can. If we do, we can acquire better
> feedback and more informed suggestions for improvement.
>
> We use quite a few nonstandard patterns and components within
> the Maven3 core - so let me suggest some refactoring ideas,
> which I believe will simplify and augment Maven's internals
> in upcoming releases.
>
> Model improvements:
> a) Xpp3 --> JAXB.
> We use Xpp3 to move entities to/from XML.
> The JSE standard is JAXB which could generate both
> XML and XSD documents for all our projects.
> We need only add JAXB annotations to our classes
> and properties for it to happen. If we feel that
> the model becomes bogged down in annotations, we
> can simply create our own compound annotations
> to reduce clutter.
>
> b) .mdo --> .java.
> We use Modello to generate large portions of the
> mainly static central parts of Maven. I believe we
> would do better without generated code within the
> Maven distribution, for 3 reasons:
>
> 1) Java is simple to read, understand and refactor.
> XML source files - such as Modello's - are neither.
> For that reason alone, we should contemplate removing
> a code generation tool. Moreover, to properly handle
> changes in the Maven model, one needs to understand
> Modello. This increases the time required to get started
> in committing patches and ideas to the Maven core/model.
>
> 2) The Maven model is largely stable, so code generation
> shouldn't really be needed. It's easier just to remove
> the code generation and commit well-written Java code.
>
> 3) Generated code tends to contain quite a number of
> no-op setters/getters (i.e. bloat), take poor use of
> OO constructs such as inheritance (we generate no
> abstract classes with common/template methods for use
> in several subclasses) and provide somewhat poor javadoc.
>
> This discussion can be exemplified with the setter below,
> which provides no parameter validation
> (i.e. "no-op setter antipattern"), not quite a sensible
> JavaDoc and no explanation of its parameter's significance.
> While I believe that most of us will eventually understand
> what goes on here, I suggest that overall code quality is
> reduced by the generation tool. Let's move to a Java model.
>
> /**
> * Set specifies that this profile will be activated when
> * matching operating system
> * attributes are detected.
> *
> * @param os
> */
> public void setOs( ActivationOS os )
> {
> this.os = os;
> } //-- void setOs( ActivationOS )
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
> ---------------------------------------------------------------------
> 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: Use of standards in the Maven core
Posted by nicolas de loof <ni...@gmail.com>.
I may be wrong regarding maven3-core, but AFAIK most code (including some
plugins) related to POM parsing use Xpp3Reader, as we don't provide an
abstraction API for POM parsing. Such a migration to JAXB (or other),
without consideration to the technical beneficts, would require a
compatibility layer. Can we provide some Xpp3-compliant API on top of JAXB ?
2010/11/12 Lennart Jorelid <lj...@jguru.se>
> Hello all,
>
> I must confess I appreciate standards in larger projects.
> Unless there are solid technology-based reasons not to use
> existing standards, I say we should strive to use standards
> as often as we can. If we do, we can acquire better
> feedback and more informed suggestions for improvement.
>
> We use quite a few nonstandard patterns and components within
> the Maven3 core - so let me suggest some refactoring ideas,
> which I believe will simplify and augment Maven's internals
> in upcoming releases.
>
> Model improvements:
> a) Xpp3 --> JAXB.
> We use Xpp3 to move entities to/from XML.
> The JSE standard is JAXB which could generate both
> XML and XSD documents for all our projects.
> We need only add JAXB annotations to our classes
> and properties for it to happen. If we feel that
> the model becomes bogged down in annotations, we
> can simply create our own compound annotations
> to reduce clutter.
>
> b) .mdo --> .java.
> We use Modello to generate large portions of the
> mainly static central parts of Maven. I believe we
> would do better without generated code within the
> Maven distribution, for 3 reasons:
>
> 1) Java is simple to read, understand and refactor.
> XML source files - such as Modello's - are neither.
> For that reason alone, we should contemplate removing
> a code generation tool. Moreover, to properly handle
> changes in the Maven model, one needs to understand
> Modello. This increases the time required to get started
> in committing patches and ideas to the Maven core/model.
>
> 2) The Maven model is largely stable, so code generation
> shouldn't really be needed. It's easier just to remove
> the code generation and commit well-written Java code.
>
> 3) Generated code tends to contain quite a number of
> no-op setters/getters (i.e. bloat), take poor use of
> OO constructs such as inheritance (we generate no
> abstract classes with common/template methods for use
> in several subclasses) and provide somewhat poor javadoc.
>
> This discussion can be exemplified with the setter below,
> which provides no parameter validation
> (i.e. "no-op setter antipattern"), not quite a sensible
> JavaDoc and no explanation of its parameter's significance.
> While I believe that most of us will eventually understand
> what goes on here, I suggest that overall code quality is
> reduced by the generation tool. Let's move to a Java model.
>
> /**
> * Set specifies that this profile will be activated when
> * matching operating system
> * attributes are detected.
> *
> * @param os
> */
> public void setOs( ActivationOS os )
> {
> this.os = os;
> } //-- void setOs( ActivationOS )
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL: www.jguru.se
> | Phone
> | (skype): jgurueurope
> | (intl): +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>