You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michal Maczka <mm...@interia.pl> on 2003/06/24 21:27:15 UTC
Responsibility - was [RE: Simian Plugin (fully documented and ready to use)\
Just wanted to express my opinion about new plugins.
I don't think that we should add more plugins to maven, unless they are
really "core plugins".
I think we have quite a lot of dead plugins and many broken plugins,
I like more the idea of having this plugin elsewhere, so original plugin
authors
can take responsibility.
Knowing Aslak's skills I have no doubt that Maven team can give him access
right
to CVS repository to let him maintain this plugin but I want to discuss
general policy regarding this subject.
I think Aslak has a lot of experience with such problems from XDoclet
project.
Simply any plugin which is based on external libraries is very sensitive to
any changes in those
libraries. For example Hibernate, Torque, JBoss plugins will be broken once
there is minor change in
those project. Keeping all plugin up to date in enormous work.
>From the other hand I feel that Maven should have a catalog of known
"foreign" plugins
( in form both of web site, and machine readable file format (XML ?), so any
plugin can be downloaded automatically)
This will not only improve quality of code which is kept in our CVS
repository, but also
will increase the number of people which can actively work on plugins and
having cvs access rights, so
also plugin will be better.
What you think?
Michal
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: Tuesday, June 24, 2003 8:54 PM
> To: 'Maven Developers List'
> Cc: simon@redhillconsulting.com.au; aslak@thoughtworks.net
> Subject: RE: Simian Plugin (fully documented and ready to use)
>
>
> Hi Aslak,
>
> I love the idea of CPD/Simian. However, before we can commit anything
> here we would need agreement from redhillconsulting.com that we can put
> the simian jar in the Maven remote repository on ibiblio.
>
> If we dont get this agreement, we could still store this plugin in the
> SF mavne-plugins project and users would need to download the simian jar
> and put it manually in their local repository.
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Aslak Hellesøy [mailto:aslak@thoughtworks.net]
> > Sent: 24 June 2003 13:58
> > To: Maven Developers List
> > Cc: simon@redhillconsulting.com.au
> > Subject: Simian Plugin (fully documented and ready to use)
> >
> > It seems Maven's JIRA still doesn't notify this list, so here I go...
> >
> > Simian (http://www.redhillconsulting.com.au/products/simian/index.html
> )
> > is a great little tool that detects duplicate source code. Very much
> > like PMD's CPD (http://pmd.sourceforge.net/cpd.html), but a _lot_
> faster.
> >
> > I have written a Maven report plugin for Simian that I'd like to
> > contribute to Maven. Have a look at some sample reports:
> >
> > http://www.picocontainer.org/simian-report.html
> > http://www.nanocontainer.org/simian-report.html
> >
> > It would be really nice to have the Simian Report included in the
> > standard reports, as it reveals refactoring candidates and is
> something
> > every sound project should have!
> >
> > It's all in JIRA:
> > http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-516
> >
> > Cheers,
> > Aslak
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ----------------------------------------------------------------------
> Klikaj!!! I skorzystaj!!! >>> http://link.interia.pl/f1739
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Aslak Hellesøy <as...@thoughtworks.net>.
Michal Maczka wrote:
>Just wanted to express my opinion about new plugins.
>
>I don't think that we should add more plugins to maven, unless they are
>really "core plugins".
>
>I think we have quite a lot of dead plugins and many broken plugins,
>
>I like more the idea of having this plugin elsewhere, so original plugin
>authors
>can take responsibility.
>
>Knowing Aslak's skills I have no doubt that Maven team can give him access
>right
>to CVS repository to let him maintain this plugin but I want to discuss
>general policy regarding this subject.
>
>I think Aslak has a lot of experience with such problems from XDoclet
>project.
>Simply any plugin which is based on external libraries is very sensitive to
>any changes in those
>libraries. For example Hibernate, Torque, JBoss plugins will be broken once
>there is minor change in
>those project. Keeping all plugin up to date in enormous work.
>
>>>From the other hand I feel that Maven should have a catalog of known
>"foreign" plugins
>( in form both of web site, and machine readable file format (XML ?), so any
>plugin can be downloaded automatically)
>
>This will not only improve quality of code which is kept in our CVS
>repository, but also
>will increase the number of people which can actively work on plugins and
>having cvs access rights, so
>also plugin will be better.
>
>
>What you think?
>
>
Good call! XDoclet2's strategy is to delegate plugin development,
maintenance and distribution to 3rd party vendors/projects. This
increases the probability of plugins keeping up to date with the product
they relate to, and lets the core team focus on the core. XDoclet2 will
only maintain a very very sparse set of plugins.
I think Maven could benefit from a similar strategy, as could many other
projects/products.
However, there is a crucial thing that needs to be in place before this
can be truly effective: Transparency for the users. They shouldn't have
to trawl the web for plugins and documentation in a gazillion different
places. It should be centralised.
That means some service where plugins (and documentation) can be
registered, and some mechanism that can actually retrieve them from
wherever they live (not only at ibiblio, but anywhere!)
This is a concept that applies to a lot of different platforms: Maven,
XDoclet, Ant, IDEs, you name it. Put in other words, the aforementioned
"containers" should be able to locate and access "components". And there
should be a nice way for plugin developers for various platforms to
register their plugin.
What I'm thinking about here is a lookup-service that runs as a server,
and can be used by various platforms. Some kind of web service thingy,
but not quite. I'd like to hear people's thought about this and whether
you think a new project should be sparked off somewhere to implement
(and possibly host) such services.
>Michal
>
>
>
>>-----Original Message-----
>>From: Vincent Massol [mailto:vmassol@pivolis.com]
>>Sent: Tuesday, June 24, 2003 8:54 PM
>>To: 'Maven Developers List'
>>Cc: simon@redhillconsulting.com.au; aslak@thoughtworks.net
>>Subject: RE: Simian Plugin (fully documented and ready to use)
>>
>>
>>Hi Aslak,
>>
>>I love the idea of CPD/Simian. However, before we can commit anything
>>here we would need agreement from redhillconsulting.com that we can put
>>the simian jar in the Maven remote repository on ibiblio.
>>
>>If we don’t get this agreement, we could still store this plugin in the
>>SF mavne-plugins project and users would need to download the simian jar
>>and put it manually in their local repository.
>>
>>Thanks
>>-Vincent
>>
>>
>>
>>>-----Original Message-----
>>>From: Aslak Hellesøy [mailto:aslak@thoughtworks.net]
>>>Sent: 24 June 2003 13:58
>>>To: Maven Developers List
>>>Cc: simon@redhillconsulting.com.au
>>>Subject: Simian Plugin (fully documented and ready to use)
>>>
>>>It seems Maven's JIRA still doesn't notify this list, so here I go...
>>>
>>>Simian (http://www.redhillconsulting.com.au/products/simian/index.html
>>>
>>>
>>)
>>
>>
>>>is a great little tool that detects duplicate source code. Very much
>>>like PMD's CPD (http://pmd.sourceforge.net/cpd.html), but a _lot_
>>>
>>>
>>faster.
>>
>>
>>>I have written a Maven report plugin for Simian that I'd like to
>>>contribute to Maven. Have a look at some sample reports:
>>>
>>>http://www.picocontainer.org/simian-report.html
>>>http://www.nanocontainer.org/simian-report.html
>>>
>>>It would be really nice to have the Simian Report included in the
>>>standard reports, as it reveals refactoring candidates and is
>>>
>>>
>>something
>>
>>
>>>every sound project should have!
>>>
>>>It's all in JIRA:
>>>http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-516
>>>
>>>Cheers,
>>>Aslak
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>>
>>
>>----------------------------------------------------------------------
>>Klikaj!!! I skorzystaj!!! >>> http://link.interia.pl/f1739
>>
>>
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>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: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-06-24 at 17:19, Rafal Krzewski wrote:
> Michal Maczka wrote:
>
> C - core - needed to perform basic tasks
> M - actively maintained
> O - obsoleted by other plugins
> B - broken
> # aspectj M (vmassol, jvanzyl 1.1)
> # codeswitcher M
> # genapp M C (used for generating sample projects)
> # idea M (jvanzyl
> # plexus M (jvanzyl>
> # plugin C (use for bootstrap)
> # runner M (jvanzyl)
> # sea M (jvanzyl>
> # vdoclet M (jvanzyl)
All the Ms can definitely be moved elsewhere at some point.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Bear Giles <bg...@coyotesong.com>.
Rafal Krzewski wrote:
> Michal Maczka wrote:
> I second Michal's opinion that we should not put any more plugins into
> maven repository, and that some of the existing one should move away
> onto another CVS repo on maven.apache.org or even to the repos of
> their associated software projects.
I haven't had the time to review the code at all, but this is
where security policies and the like should come into play.
The core plugins distributed with Maven could one security policy,
fairly liberal because they've been vetted by developers. These
plugins would handle the primary build mechanisms and one or more
facilities to download other plugins.
Anything they download - including other plugins - will default to
more restrictive policies. E.g., perhaps no downloaded plugin can
download any other plugin, but it can download other files at the
same site.
Individual sites can override the security policy, of course. But
as I've mentioned before unrestricted downloads and execution of
unknown code makes me nervous.
As a side note - is there a log of what's downloaded (or
uploaded!) anywhere, e.g., perhaps through an instrumented
java.net package?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Rafal Krzewski <Ra...@caltha.pl>.
dion@multitask.com.au wrote:
>>It would be nice if one of the commiters checked in a plugin-map.xml
>>xdoc that would contain a list of plugins similar to that one above, and
>>then all commiters would add their name next to the plugins they are
>>willing to work on, and their name in ( ) next to the plugins they
>>know good enough to fix if they happen to break.
>
> That's what project.xml is for - if they're willing to work on it, add
> themselves as a developer/contributor
You are right, it's even better - provided that the information in the
POMs is accurate - it would be gread if the commiters checked their entries.
>>I second Michal's opinion that we should not put any more plugins into
>>maven repository, and that some of the existing one should move away
>>onto another CVS repo on maven.apache.org or even to the repos of
>>their associated software projects.
>
> I thought maven-plugin was to be the new apache cvs repo for plugins once
> we worked out how to declare plugin usage.
Yup, that repo is up already. Non core plugins could move there when
the discovery/dependency stuff works.
> I believe it was agreed to use <type>maven-plugin</type>
It's OK with me if it is an established policy. I would personaly opt
for shorter 'plugin' name, because there is no ambiguity here - what
other type of plugins artifact could we have?
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Ben Walding <de...@walding.com>.
Vincent Massol wrote:
>Hi Ben,
>
>Cool, but why don't you use the Apache Wiki? :-) Actually, I don't
>really care which wiki we use but I think it's better to use only one.
>
>
I hate usemod (it's ugly, it's primitive, it's limited). Up until now it
was a means to an end. We've now got something better and the content
could be easily ported.
If we decide to move what little information we have in that wiki out,
I'll do the "conversion". If we decide we want a dedicated wiki and not
a codehaus branded one, that can also be arranged. If the masses want
to stay with usemod, that can be arranged, but only after they are
beaten with a large bat.
>Also, I think it is duplicate information from the one found in
>project.xml.
>
>Why don't we instead generate a page on
>http://maven.apache.org/reference/plugins/ that would extract
><developer> information from the project.xml ?
>
Well that would be an better way, but developer information is generally
out-of-date also (developers are never removed). Cvs is the best way
to go. Just trap the last few people to touch the plugin.
>Also, I'm not convinced yet that there should core plugins versus
>non-core plugins. I think all plugins must be viewed equals. Otherwise,
>we will not resist the temptation to do some "hacks/shotcuts" such as
>the one done in the jar plugin which calls test:test when a jar is
>generated. There are other test plugins that would also like to do that
>for example. etc
>
I see a core plugin as something that maven provides directly and is
required to build maven. eg. jar / test etc
Non core would be an extension such war or ear.
External would be plugins outside the control of maven
XDoc falls into a middle ground as it isn't truly required to build maven.
Also, I think that we need plugin metadata to stop people hooking inside
plugins - eg.
http://wiki.codehaus.org/general/Maven_2fPluginMetadata
Cheers,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Responsibility - was [RE: Simian Plugin (fully documented and ready to use)\
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Ben,
Cool, but why don't you use the Apache Wiki? :-) Actually, I don't
really care which wiki we use but I think it's better to use only one.
Also, I think it is duplicate information from the one found in
project.xml.
Why don't we instead generate a page on
http://maven.apache.org/reference/plugins/ that would extract
<developer> information from the project.xml ?
Also, I'm not convinced yet that there should core plugins versus
non-core plugins. I think all plugins must be viewed equals. Otherwise,
we will not resist the temptation to do some "hacks/shotcuts" such as
the one done in the jar plugin which calls test:test when a jar is
generated. There are other test plugins that would also like to do that
for example. etc
Thanks
-Vincent
> -----Original Message-----
> From: Ben Walding [mailto:default0001@walding.com]
> Sent: 25 June 2003 10:40
> To: Maven Developers List
> Subject: Re: Responsibility - was [RE: Simian Plugin (fully documented
and
> ready to use)\
>
> See http://wiki.codehaus.org/general/Maven_2fPluginOwners
>
> I'll aggregate the 3 emails on this already, but all additional bits
> should probably go in the wiki directly.
>
> This email was out of control :)
>
> Vincent Massol wrote:
>
> >
> >
> >>-----Original Message-----
> >>From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> >>Sent: 25 June 2003 02:32
> >>To: Maven Developers List
> >>Subject: Re: Responsibility - was [RE: Simian Plugin (fully
documented
> >>
> >>
> >and
> >
> >
> >>ready to use)\
> >>
> >>
> >
> >[snip]
> >
> >
> >
> >>>C - core - needed to perform basic tasks
> >>>M - actively maintained
> >>>O - obsoleted by other plugins
> >>>B - broken
> >>>
> >>># ant
> >>>
> >>>
> >>AFAIK, this is 'M' - stable but actively maintained.
> >>
> >>
> >>
> >>># antlr
> >>># appserver
> >>># artifact M C
> >>># ashkelon
> >>># aspectj
> >>>
> >>>
> >>I would put this at M
> >>
> >>
> >>># cactus M
> >>># castor
> >>># changelog C
> >>>
> >>>
> >>M
> >>
> >>
> >>># changes C
> >>>
> >>>
> >>M
> >>
> >>
> >>># checkstyle M C
> >>># clean C
> >>>
> >>>
> >>M - I changed it not long back.
> >>
> >>
> >>># clover M
> >>># codeswitcher
> >>># console C
> >>># deploy O?
> >>># developer-activity C
> >>>
> >>>
> >>M
> >>
> >>
> >>># dist C
> >>># docbook M
> >>># ear C
> >>>
> >>>
> >>M
> >>
> >>
> >>># eclipse
> >>>
> >>>
> >>M
> >>
> >>
> >>># ejb
> >>>
> >>>
> >>M
> >>
> >>
> >>># examples M
> >>># faq
> >>># file-activity C
> >>>
> >>>
> >>M
> >>
> >>
> >>># genapp
> >>>
> >>>
> >>M
> >>
> >>
> >>># gump
> >>>
> >>>
> >>M
> >>
> >>
> >>># hibernate
> >>># html2xdoc
> >>># idea
> >>># j2ee O
> >>># jalopy
> >>># jar C
> >>>
> >>>
> >>M
> >>
> >>
> >>># java C
> >>>
> >>>
> >>M
> >>
> >>
> >>># javadoc C
> >>>
> >>>
> >>M
> >>
> >>
> >>># jboss M
> >>># jbuilder M
> >>># jdee
> >>># jdepend
> >>># jdeveloper
> >>># jdiff
> >>># jellydoc
> >>>
> >>>
> >>M
> >>
> >>
> >>># jnlp
> >>>
> >>>
> >>M
> >>
> >>
> >>># junit-report
> >>>
> >>>
> >>M
> >>
> >>
> >>># junitdoclet
> >>>
> >>>
> >>M
> >>
> >>
> >>># jxr C
> >>># latex
> >>># latka
> >>>
> >>>
> >>M
> >>
> >>
> >>># license C
> >>>
> >>>
> >>M
> >>
> >>
> >>># linkcheck M C
> >>># native
> >>># pdf M
> >>># perforce
> >>># plexus
> >>># plugin
> >>>
> >>>
> >>M
> >>
> >>
> >>># pmd
> >>>
> >>>
> >
> >M
> >
> >
> >
> >>># pom C
> >>>
> >>>
> >>M
> >>
> >>
> >>># release C
> >>># repository
> >>>
> >>>
> >>M C
> >>
> >>
> >>># runner
> >>># sea
> >>># shell
> >>># site
> >>># statcvs C
> >>>
> >>>
> >
> >M (I am maintaining it although not using it myself. I someone
reports
> >it is broken, I'll fix it. But no one has done so AFAIK).
> >
> >
> >
> >>># struts
> >>># summit
> >>># tasklist C
> >>>
> >>>
> >>M
> >>
> >>
> >>># test C
> >>>
> >>>
> >>M
> >>
> >>
> >>># torque
> >>># touchstone M C
> >>># touchstone-partner M C
> >>># uberjar
> >>>
> >>>
> >>M
> >>
> >>
> >>># vdoclet
> >>># war
> >>>
> >>>
> >>M
> >>
> >>
> >>># was40 M
> >>># webserver O?
> >>>
> >>>
> >>M - peter lynch has updated this recently.
> >>
> >>
> >>># wizard
> >>># word2html
> >>>
> >>>
> >>M
> >>
> >>
> >>># xdoc M C
> >>>
> >>>
> >>>
> >
> >[snip]
> >
> >I personally "maintain"/"am active" on the following:
> >
> >- cactus
> >- jboss
> >- war
> >- ear
> >- ejb
> >- pmd
> >- statcvs
> >- changes
> >- checkstyle
> >
> >I'm also probably going to tackle the aspectj one soon.
> >
> >Thanks
> >-Vincent
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Ben Walding <de...@walding.com>.
See http://wiki.codehaus.org/general/Maven_2fPluginOwners
I'll aggregate the 3 emails on this already, but all additional bits
should probably go in the wiki directly.
This email was out of control :)
Vincent Massol wrote:
>
>
>>-----Original Message-----
>>From: dion@multitask.com.au [mailto:dion@multitask.com.au]
>>Sent: 25 June 2003 02:32
>>To: Maven Developers List
>>Subject: Re: Responsibility - was [RE: Simian Plugin (fully documented
>>
>>
>and
>
>
>>ready to use)\
>>
>>
>
>[snip]
>
>
>
>>>C - core - needed to perform basic tasks
>>>M - actively maintained
>>>O - obsoleted by other plugins
>>>B - broken
>>>
>>># ant
>>>
>>>
>>AFAIK, this is 'M' - stable but actively maintained.
>>
>>
>>
>>># antlr
>>># appserver
>>># artifact M C
>>># ashkelon
>>># aspectj
>>>
>>>
>>I would put this at M
>>
>>
>>># cactus M
>>># castor
>>># changelog C
>>>
>>>
>>M
>>
>>
>>># changes C
>>>
>>>
>>M
>>
>>
>>># checkstyle M C
>>># clean C
>>>
>>>
>>M - I changed it not long back.
>>
>>
>>># clover M
>>># codeswitcher
>>># console C
>>># deploy O?
>>># developer-activity C
>>>
>>>
>>M
>>
>>
>>># dist C
>>># docbook M
>>># ear C
>>>
>>>
>>M
>>
>>
>>># eclipse
>>>
>>>
>>M
>>
>>
>>># ejb
>>>
>>>
>>M
>>
>>
>>># examples M
>>># faq
>>># file-activity C
>>>
>>>
>>M
>>
>>
>>># genapp
>>>
>>>
>>M
>>
>>
>>># gump
>>>
>>>
>>M
>>
>>
>>># hibernate
>>># html2xdoc
>>># idea
>>># j2ee O
>>># jalopy
>>># jar C
>>>
>>>
>>M
>>
>>
>>># java C
>>>
>>>
>>M
>>
>>
>>># javadoc C
>>>
>>>
>>M
>>
>>
>>># jboss M
>>># jbuilder M
>>># jdee
>>># jdepend
>>># jdeveloper
>>># jdiff
>>># jellydoc
>>>
>>>
>>M
>>
>>
>>># jnlp
>>>
>>>
>>M
>>
>>
>>># junit-report
>>>
>>>
>>M
>>
>>
>>># junitdoclet
>>>
>>>
>>M
>>
>>
>>># jxr C
>>># latex
>>># latka
>>>
>>>
>>M
>>
>>
>>># license C
>>>
>>>
>>M
>>
>>
>>># linkcheck M C
>>># native
>>># pdf M
>>># perforce
>>># plexus
>>># plugin
>>>
>>>
>>M
>>
>>
>>># pmd
>>>
>>>
>
>M
>
>
>
>>># pom C
>>>
>>>
>>M
>>
>>
>>># release C
>>># repository
>>>
>>>
>>M C
>>
>>
>>># runner
>>># sea
>>># shell
>>># site
>>># statcvs C
>>>
>>>
>
>M (I am maintaining it although not using it myself. I someone reports
>it is broken, I'll fix it. But no one has done so AFAIK).
>
>
>
>>># struts
>>># summit
>>># tasklist C
>>>
>>>
>>M
>>
>>
>>># test C
>>>
>>>
>>M
>>
>>
>>># torque
>>># touchstone M C
>>># touchstone-partner M C
>>># uberjar
>>>
>>>
>>M
>>
>>
>>># vdoclet
>>># war
>>>
>>>
>>M
>>
>>
>>># was40 M
>>># webserver O?
>>>
>>>
>>M - peter lynch has updated this recently.
>>
>>
>>># wizard
>>># word2html
>>>
>>>
>>M
>>
>>
>>># xdoc M C
>>>
>>>
>>>
>
>[snip]
>
>I personally "maintain"/"am active" on the following:
>
>- cactus
>- jboss
>- war
>- ear
>- ejb
>- pmd
>- statcvs
>- changes
>- checkstyle
>
>I'm also probably going to tackle the aspectj one soon.
>
>Thanks
>-Vincent
>
>
>---------------------------------------------------------------------
>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: Responsibility - was [RE: Simian Plugin (fully documented and ready to use)\
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 25 June 2003 02:32
> To: Maven Developers List
> Subject: Re: Responsibility - was [RE: Simian Plugin (fully documented
and
> ready to use)\
[snip]
> > C - core - needed to perform basic tasks
> > M - actively maintained
> > O - obsoleted by other plugins
> > B - broken
> >
> > # ant
> AFAIK, this is 'M' - stable but actively maintained.
>
> > # antlr
> > # appserver
> > # artifact M C
> > # ashkelon
> > # aspectj
> I would put this at M
> > # cactus M
> > # castor
> > # changelog C
> M
> > # changes C
> M
> > # checkstyle M C
> > # clean C
> M - I changed it not long back.
> > # clover M
> > # codeswitcher
> > # console C
> > # deploy O?
> > # developer-activity C
> M
> > # dist C
> > # docbook M
> > # ear C
> M
> > # eclipse
> M
> > # ejb
> M
> > # examples M
> > # faq
> > # file-activity C
> M
> > # genapp
> M
> > # gump
> M
> > # hibernate
> > # html2xdoc
> > # idea
> > # j2ee O
> > # jalopy
> > # jar C
> M
> > # java C
> M
> > # javadoc C
> M
> > # jboss M
> > # jbuilder M
> > # jdee
> > # jdepend
> > # jdeveloper
> > # jdiff
> > # jellydoc
> M
> > # jnlp
> M
> > # junit-report
> M
> > # junitdoclet
> M
> > # jxr C
> > # latex
> > # latka
> M
> > # license C
> M
> > # linkcheck M C
> > # native
> > # pdf M
> > # perforce
> > # plexus
> > # plugin
> M
> > # pmd
M
> > # pom C
> M
> > # release C
> > # repository
> M C
> > # runner
> > # sea
> > # shell
> > # site
> > # statcvs C
M (I am maintaining it although not using it myself. I someone reports
it is broken, I'll fix it. But no one has done so AFAIK).
> > # struts
> > # summit
> > # tasklist C
> M
> > # test C
> M
> > # torque
> > # touchstone M C
> > # touchstone-partner M C
> > # uberjar
> M
> > # vdoclet
> > # war
> M
> > # was40 M
> > # webserver O?
> M - peter lynch has updated this recently.
> > # wizard
> > # word2html
> M
> > # xdoc M C
> >
[snip]
I personally "maintain"/"am active" on the following:
- cactus
- jboss
- war
- ear
- ejb
- pmd
- statcvs
- changes
- checkstyle
I'm also probably going to tackle the aspectj one soon.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and ready to
use)\
Posted by di...@multitask.com.au.
Rafal Krzewski <Ra...@caltha.pl> wrote on 25/06/2003 07:19:26 AM:
> I daresay that 2/3 of exising maven plugins is broken and/or orphaned.
> This is obviously an unacceptable situation.
I daresay you're wrong, and would love to see a change :-)
> Below there's a list of plugins taken from current website. I've put
> marks next to them representing *my personal* opinion on the pluin's
> condition.
>
> C - core - needed to perform basic tasks
> M - actively maintained
> O - obsoleted by other plugins
> B - broken
>
> # ant
AFAIK, this is 'M' - stable but actively maintained.
> # antlr
> # appserver
> # artifact M C
> # ashkelon
> # aspectj
I would put this at M
> # cactus M
> # castor
> # changelog C
M
> # changes C
M
> # checkstyle M C
> # clean C
M - I changed it not long back.
> # clover M
> # codeswitcher
> # console C
> # deploy O?
> # developer-activity C
M
> # dist C
> # docbook M
> # ear C
M
> # eclipse
M
> # ejb
M
> # examples M
> # faq
> # file-activity C
M
> # genapp
M
> # gump
M
> # hibernate
> # html2xdoc
> # idea
> # j2ee O
> # jalopy
> # jar C
M
> # java C
M
> # javadoc C
M
> # jboss M
> # jbuilder M
> # jdee
> # jdepend
> # jdeveloper
> # jdiff
> # jellydoc
M
> # jnlp
M
> # junit-report
M
> # junitdoclet
M
> # jxr C
> # latex
> # latka
M
> # license C
M
> # linkcheck M C
> # native
> # pdf M
> # perforce
> # plexus
> # plugin
M
> # pmd
> # pom C
M
> # release C
> # repository
M C
> # runner
> # sea
> # shell
> # site
> # statcvs C
> # struts
> # summit
> # tasklist C
M
> # test C
M
> # torque
> # touchstone M C
> # touchstone-partner M C
> # uberjar
M
> # vdoclet
> # war
M
> # was40 M
> # webserver O?
M - peter lynch has updated this recently.
> # wizard
> # word2html
M
> # xdoc M C
>
> There is a few plugins there that I don't know/understand so my marks
> may be off base here and there.
>
> It would be nice if one of the commiters checked in a plugin-map.xml
> xdoc that would contain a list of plugins similar to that one above, and
> then all commiters would add their name next to the plugins they are
> willing to work on, and their name in ( ) next to the plugins they
> know good enough to fix if they happen to break.
That's what project.xml is for - if they're willing to work on it, add
themselves as a developer/contributor
> As for the core/obsolete status of each plugin an IRC discussion with
> a sigle person writing down resolutions would probably be best.
>
> I second Michal's opinion that we should not put any more plugins into
> maven repository, and that some of the existing one should move away
> onto another CVS repo on maven.apache.org or even to the repos of
> their associated software projects.
I thought maven-plugin was to be the new apache cvs repo for plugins once
we worked out how to declare plugin usage.
> The notation for those dependencies is basicly in place, we might need
> to introduce addtional artifact types for that. Here's a snippet from
> a hypotetical plugin's project.xml:
>
> <dependencies>
> <dependency>
> <dependencyType>runtime</dependencyType>
> <groupId>maven.apache.org</groupId>
> <artifactId>maven-core-plugin</artifactId>
I believe it was agreed to use <type>maven-plugin</type>
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Re: Responsibility - was [RE: Simian Plugin (fully documented and ready to use)\
Posted by bob mcwhirter <bo...@werken.com>.
> # antlr M (bob)
> # ashkelon M (ben)
> # jalopy M (jcej, I think)
> # latex M (bob)
> # perforce M (jcej)
> # uberjar M (bob, pete)
-bob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Responsibility - was [RE: Simian Plugin (fully documented and
ready to use)\
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Michal Maczka wrote:
> Just wanted to express my opinion about new plugins.
>
> I don't think that we should add more plugins to maven, unless they are
> really "core plugins".
>
> I think we have quite a lot of dead plugins and many broken plugins,
>
> I like more the idea of having this plugin elsewhere, so original plugin
> authors
> can take responsibility.
I daresay that 2/3 of exising maven plugins is broken and/or orphaned.
This is obviously an unacceptable situation.
Below there's a list of plugins taken from current website. I've put
marks next to them representing *my personal* opinion on the pluin's
condition.
C - core - needed to perform basic tasks
M - actively maintained
O - obsoleted by other plugins
B - broken
# ant
# antlr
# appserver
# artifact M C
# ashkelon
# aspectj
# cactus M
# castor
# changelog C
# changes C
# checkstyle M C
# clean C
# clover M
# codeswitcher
# console C
# deploy O?
# developer-activity C
# dist C
# docbook M
# ear C
# eclipse
# ejb
# examples M
# faq
# file-activity C
# genapp
# gump
# hibernate
# html2xdoc
# idea
# j2ee O
# jalopy
# jar C
# java C
# javadoc C
# jboss M
# jbuilder M
# jdee
# jdepend
# jdeveloper
# jdiff
# jellydoc
# jnlp
# junit-report
# junitdoclet
# jxr C
# latex
# latka
# license C
# linkcheck M C
# native
# pdf M
# perforce
# plexus
# plugin
# pmd
# pom C
# release C
# repository
# runner
# sea
# shell
# site
# statcvs C
# struts
# summit
# tasklist C
# test C
# torque
# touchstone M C
# touchstone-partner M C
# uberjar
# vdoclet
# war
# was40 M
# webserver O?
# wizard
# word2html
# xdoc M C
There is a few plugins there that I don't know/understand so my marks
may be off base here and there.
It would be nice if one of the commiters checked in a plugin-map.xml
xdoc that would contain a list of plugins similar to that one above, and
then all commiters would add their name next to the plugins they are
willing to work on, and their name in ( ) next to the plugins they
know good enough to fix if they happen to break.
As for the core/obsolete status of each plugin an IRC discussion with
a sigle person writing down resolutions would probably be best.
I second Michal's opinion that we should not put any more plugins into
maven repository, and that some of the existing one should move away
onto another CVS repo on maven.apache.org or even to the repos of
their associated software projects.
At the same time I agree with Vincent that this is not really feasible
ATM, because we lack a mechanism for expressing plugin runtime
dependencies - both on Maven core version and on other plugins / versions.
The notation for those dependencies is basicly in place, we might need
to introduce addtional artifact types for that. Here's a snippet from
a hypotetical plugin's project.xml:
<dependencies>
<dependency>
<dependencyType>runtime</dependencyType>
<groupId>maven.apache.org</groupId>
<artifactId>maven-core-plugin</artifactId>
<artifactType>plugin</artifactType>
<version>1.0</version>
<versionMatch>compatible</versionMatch>
</dependency>
<dependency>
<dependencyType>build</dependencyType>
<dependencyType>runtime</dependencyType>
<groupId>maven.apache.org</groupId>
<artifactId>maven-</artifactId>
<artifactType>maven-artifact-plugin</artifactType>
<version>1.0</version>
<versionMatch>equivalent</versionMatch>
<dependency>
</dependencies>
tags used:
<dependencyType> - Michal's <kind>: build,runtime,test - a hint for
grouping dependencies together for different uses throughout the system
<artifactType> - current <type>: jar,war,ear,plugin... - renamed for
contrast with the above
<versionMatch> : perfect,equivalent,compatible,greaterOrEqual - a hint
for the Dependency resolver to allow imperfect matches, using Eclipse
conventions (when 1.1.0 is requested, 1.1.1 is considered equivalent,
1.2.0 compatible, and 2.0.0 greaterOrEqual)
maven-core-plugin - maven could ship with a dummy plugin bearing the
same version tag as the core, that could be used for expressing
projects/plugins dependency on particular version of the core without
introducing a degenerate <artifactType> (a type that would be valid
for only one special artifact).
Even if all of the above seems easy, it is not. The *real* fun
begins when a project insists on using plugins that have conflicting
requirements. Once plugins are distributed independently from the
core and one another this will be a frequent situation, and maven
will need to go to great lenghts to help the users out of the mess.
Isolating plugins and merging them into mutualy compatible clusters
by the means of serious classworld jugglig comes to my mind...
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Responsibility - was [RE: Simian Plugin (fully documented and ready to use)\
Posted by Vincent Massol <vm...@pivolis.com>.
My view is very simple: Let's move all plugins outside the core of
Maven. However, ATM it is not done for the following reason:
- There is no mechanism for a project to tell which plugins it wants to
use (and in what version).
[Of course there would a list of default plugins with default versions
when you download maven so that you don't need to specify the full list
of plugins to use in each project].
Once we have this, I'll be the first to vote a big +1 to have each
plugin as a separate project with its own lifecycle.
-Vincent
> -----Original Message-----
> From: Michal Maczka [mailto:mmaczka@interia.pl]
> Sent: 24 June 2003 21:27
> To: Maven Developers List
> Subject: Responsibility - was [RE: Simian Plugin (fully documented and
> ready to use)\
>
> Just wanted to express my opinion about new plugins.
>
> I don't think that we should add more plugins to maven, unless they
are
> really "core plugins".
>
> I think we have quite a lot of dead plugins and many broken plugins,
>
> I like more the idea of having this plugin elsewhere, so original
plugin
> authors
> can take responsibility.
>
> Knowing Aslak's skills I have no doubt that Maven team can give him
access
> right
> to CVS repository to let him maintain this plugin but I want to
discuss
> general policy regarding this subject.
>
> I think Aslak has a lot of experience with such problems from XDoclet
> project.
>
> Simply any plugin which is based on external libraries is very
sensitive
> to
> any changes in those
> libraries. For example Hibernate, Torque, JBoss plugins will be broken
> once
> there is minor change in
> those project. Keeping all plugin up to date in enormous work.
>
> From the other hand I feel that Maven should have a catalog of known
> "foreign" plugins
> ( in form both of web site, and machine readable file format (XML ?),
so
> any
> plugin can be downloaded automatically)
>
> This will not only improve quality of code which is kept in our CVS
> repository, but also
> will increase the number of people which can actively work on plugins
and
> having cvs access rights, so
> also plugin will be better.
>
>
> What you think?
>
> Michal
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@pivolis.com]
> > Sent: Tuesday, June 24, 2003 8:54 PM
> > To: 'Maven Developers List'
> > Cc: simon@redhillconsulting.com.au; aslak@thoughtworks.net
> > Subject: RE: Simian Plugin (fully documented and ready to use)
> >
> >
> > Hi Aslak,
> >
> > I love the idea of CPD/Simian. However, before we can commit
anything
> > here we would need agreement from redhillconsulting.com that we can
put
> > the simian jar in the Maven remote repository on ibiblio.
> >
> > If we dont get this agreement, we could still store this plugin in
the
> > SF mavne-plugins project and users would need to download the simian
jar
> > and put it manually in their local repository.
> >
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Aslak Hellesøy [mailto:aslak@thoughtworks.net]
> > > Sent: 24 June 2003 13:58
> > > To: Maven Developers List
> > > Cc: simon@redhillconsulting.com.au
> > > Subject: Simian Plugin (fully documented and ready to use)
> > >
> > > It seems Maven's JIRA still doesn't notify this list, so here I
go...
> > >
> > > Simian
(http://www.redhillconsulting.com.au/products/simian/index.html
> > )
> > > is a great little tool that detects duplicate source code. Very
much
> > > like PMD's CPD (http://pmd.sourceforge.net/cpd.html), but a _lot_
> > faster.
> > >
> > > I have written a Maven report plugin for Simian that I'd like to
> > > contribute to Maven. Have a look at some sample reports:
> > >
> > > http://www.picocontainer.org/simian-report.html
> > > http://www.nanocontainer.org/simian-report.html
> > >
> > > It would be really nice to have the Simian Report included in the
> > > standard reports, as it reveals refactoring candidates and is
> > something
> > > every sound project should have!
> > >
> > > It's all in JIRA:
> > > http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-516
> > >
> > > Cheers,
> > > Aslak
> > >
> > >
> > >
---------------------------------------------------------------------
> > > 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
> >
> >
> >
----------------------------------------------------------------------
> > Klikaj!!! I skorzystaj!!! >>> http://link.interia.pl/f1739
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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