You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/04/08 19:22:42 UTC
[jira] Created: (MNG-275) design and publish the Mojo API
design and publish the Mojo API
-------------------------------
Key: MNG-275
URL: http://jira.codehaus.org/browse/MNG-275
Project: m2
Type: Task
Components: design
Reporter: Brett Porter
Fix For: 2.0-alpha-2
we need to solidify the Mojo API so that others can start writing them with confidence.
This includes:
- strategy for dealing with types
- dealing with responses
- reviewing logging and events
- considering whether extending a class is too cumbersome
- what basic types we might want to provide without going overboard
anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-275) design and publish the Mojo API
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_38613 ]
John Casey commented on MNG-275:
--------------------------------
Brett, is this last item (in the original issue comment) still valid? What did you mean by types?
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-275) design and publish the Mojo API
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_32101 ]
Brett Porter commented on MNG-275:
----------------------------------
I'd like to consider making the maven-plugin-api dependency optional, and review the split between maven-monitor and maven-plugin.
what is provided by the plugin interface is:
- execute() method
- setLog(Logger logger) method
The execute method can be looked up using reflection if the class does not implement Plugin.
While this could be done for setLog, the Logger must be something... I suggest that maven-plugin-api should provider the Logger interface (and only an interface - not an implementation), and a plugin wishing to Log will have to implement the Plugin interface (or extend AbstractPlugin).
So anything could use these beans by simply looking up and running the execute() method, and I believe that such means would already be valid Ant tasks as is as well as mojos (with appropriate metadata).
Then, if it implements plugin the setLog method can be called with a MavenPluginLogger or AntLogger implementation, etc.
This reduces the relevance of maven-monitor, and it may be appropriate to just take the interface from there, and then use plexus logging inside Maven itself (and provide a plexus logging implementation of the plugin's logger interface).
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-275) design and publish the Mojo API
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_38626 ]
Brett Porter commented on MNG-275:
----------------------------------
I was thinking whether there are any useful, reusable beans we might include in the API for people to use as types. I can't think of any off the top of my head, so we can just add them later as needed.
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-275) design and publish the Mojo API
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_38536 ]
John Casey commented on MNG-275:
--------------------------------
If we allow simple specification of the execute() method to be sufficient for a mojo to be a mojo (plus metadata of course), then what are the implications for the throws clause of this method? Will we be forced back into "throws Exception" or will we dictate that if the method throws anything, it must throw MojoExecutionException or a derivative of RuntimeException?
I'd probably be +1 for the latter, which is to say that we check the throws clause reflectively, and if we detect a throws clause that isn't limited to derivatives of RuntimeException or MojoExecutionException, we error out and yell at the user...I'm really not in favor of hoping that mojo developers aren't just passing exception on through the system sans interpretation, and this will be the case if we allow "throws Exception". There needs to be enough of an inconvenience to the mojo developer to think about what [s]he is doing...
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-275) design and publish the Mojo API
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=history ]
Brett Porter updated MNG-275:
-----------------------------
Comment: was deleted
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM root Element: project or model?
Posted by Joachim Schreiber <yo...@yos.biz>.
> If you'd like, you can use the same code Maven does:
> maven-model-2.0-alpha-1.jar (you'll also need plexus-utils-1.0-alpha-
> 2.jar)
>
> MavenXppReader reader = new MavenXpp3Reader();
> Model pom = reader.read( new FileReader( new File( "pom.xml" ) ) );
> (with suitable error handling on the FileReader, of course)
>
> >From that, you have pom.getName(), pom.getBuild(),
> pom.getDependencies(), etc - basically the same as XMLBeans would give
> you.
Cool, I will do this ;-)
Thanks!
yo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM root Element: project or model?
Posted by Brett Porter <br...@apache.org>.
>In the moment I have created a schema for the new m2 POM and use it with XML
>Beans for parsing the POM. Before I give the XML to the parser I add a
>science fiction namespace and good ;-)
>
>
If you'd like, you can use the same code Maven does:
maven-model-2.0-alpha-1.jar (you'll also need plexus-utils-1.0-alpha-2.jar)
MavenXppReader reader = new MavenXpp3Reader();
Model pom = reader.read( new FileReader( new File( "pom.xml" ) ) );
(with suitable error handling on the FileReader, of course)
>From that, you have pom.getName(), pom.getBuild(),
pom.getDependencies(), etc - basically the same as XMLBeans would give you.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: POM root Element: project or model?
Posted by Joachim Schreiber <yo...@yos.biz>.
> From: Brett Porter Sent: Sunday, April 17, 2005 8:14 AM
> To: Maven Developers List
> Subject: Re: POM root Element: project or model?
>
[snip]
> It's planned to provide a generated schema - however, different
> namespaces will not tend to be used inside the POM - we've looked at the
> option and preferred to keep it simple, finding no need to add them at
> this point.
>
Yes this is not really a problem for m2 ;-)
I was just playing around with the new m2 model. For me the POM is a
repository for Metadata about a project/artifact. I want to parse the
pom.xml files and transfer them to a XTM TopicMap. For XML parsing I very
often use XMLBeans... and XMLBeans needs a schema and xml instances with a
namespace.
In the moment I have created a schema for the new m2 POM and use it with XML
Beans for parsing the POM. Before I give the XML to the parser I add a
science fiction namespace and good ;-)
Yes I know this is just my personal kismet and I can live with it ;-) but
perhaps other schema and namespace aware parsers for examples in IDE's or
Tools may have the same problem.
Just an idea and a report from working with m2. Not a criticism!
yo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: POM root Element: project or model?
Posted by Brett Porter <br...@apache.org>.
Joachim Schreiber wrote:
>The Docs on m2 web site for the POM shows <model> as the root element.
>
>In the m2 cvs is a mixture of <project> and <model> elements in the pom.xml
>files.
>
>
It should be project... it is in the process of being changed. Actually,
either is valid, for now.
>What is the planned name for this element, project or model?
>
>BTW Why not using a namespace declaration (and an online accessible schema
>representation of the pom) in the pom.xml?
>
>
It's planned to provide a generated schema - however, different
namespaces will not tend to be used inside the POM - we've looked at the
option and preferred to keep it simple, finding no need to add them at
this point.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
POM root Element: project or model?
Posted by Joachim Schreiber <yo...@yos.biz>.
The Docs on m2 web site for the POM shows <model> as the root element.
In the m2 cvs is a mixture of <project> and <model> elements in the pom.xml
files.
What is the planned name for this element, project or model?
BTW Why not using a namespace declaration (and an online accessible schema
representation of the pom) in the pom.xml?
yo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-275) design and publish the Mojo API
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_32102 ]
Brett Porter commented on MNG-275:
----------------------------------
I'd like to consider making the maven-plugin-api dependency optional, and review the split between maven-monitor and maven-plugin.
what is provided by the plugin interface is:
- execute() method
- setLog(Logger logger) method
The execute method can be looked up using reflection if the class does not implement Plugin.
While this could be done for setLog, the Logger must be something... I suggest that maven-plugin-api should provider the Logger interface (and only an interface - not an implementation), and a plugin wishing to Log will have to implement the Plugin interface (or extend AbstractPlugin).
So anything could use these beans by simply looking up and running the execute() method, and I believe that such means would already be valid Ant tasks as is as well as mojos (with appropriate metadata). Note, however that most Ant tasks don't take this approach - they extend Task, and utilise several Ant types. There is also a difference between addXXX and addConfiguredXXX, the latter we don't support and the former done through setters and private field injection.
Then, if it implements plugin the setLog method can be called with a MavenPluginLogger or AntLogger implementation, etc.
This reduces the relevance of maven-monitor, and it may be appropriate to just take the interface from there, and then use plexus logging inside Maven itself (and provide a plexus logging implementation of the plugin's logger interface).
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-275) design and publish the Mojo API
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=all ]
Brett Porter closed MNG-275:
----------------------------
yup, this was all done.
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: Maven 2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Resolved: (MNG-275) design and publish the Mojo API
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-275?page=all ]
John Casey resolved MNG-275:
----------------------------
Resolution: Fixed
> design and publish the Mojo API
> -------------------------------
>
> Key: MNG-275
> URL: http://jira.codehaus.org/browse/MNG-275
> Project: m2
> Type: Task
> Components: design
> Reporter: Brett Porter
> Assignee: John Casey
> Fix For: 2.0-alpha-2
>
>
> we need to solidify the Mojo API so that others can start writing them with confidence.
> This includes:
> - strategy for dealing with types
> - dealing with responses
> - reviewing logging and events
> - considering whether extending a class is too cumbersome
> - what basic types we might want to provide without going overboard
> anything else?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org