You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by joerg <jo...@j-hohwiller.de> on 2005/07/31 22:57:47 UTC
Re: [m2] getting involved?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
thanks to all your answers to my mail.
I got some interesting links and understood
that the maven core is about 9?% done.
I will check if I am on the latest version or better
build m2 directly from svn. Maybe that is the reason why POM inheritance
did not work for me. I'll check this and if it still does not work I'll
send you the toplevel and a sub POM.
I'll pick up the suggestion to better contribute on some pluggin stuff.
I've seen on the plugin matrix that there will be no "MultiProject
Plugin". Is that because you now have "Multi-Project" by design and not
like some sort of late add-on so all plugins can support this directly?
BTW - I like plexus. Haven't noticed the project before. I had used
avalon and had a look at pico+nano before. Plexus seems to be powerfull
like avalon containers but less invasive (like the spring-framework).
Maybe I'll use that in my project. Would you again decide for plexus if
you'd choose now?
Regards
Jörg
Brett Porter wrote:
> Thanks for your kind words!
>
> Others have already answered most of this, so I'll just cover a couple
> of extra things.
>
> joerg wrote:
>
>
>>Anyways I'd like to know your ideas how
>>to handle this issue in m2 (there should be a way for the m2 user to
>>manually decide which version to use - maybe simply by defining the
>>troublecausing dependency on the toplevel project in the desired
>>version). Anyways I think that "recursive dependencies" are in general a
>>good idea.
>
>
> As already pointed out, we have dependency mediation, which there is
> info on the wiki about. Basically:
> - the version you give is a suggestion, and it figures out the best one
> for you
> - you can specify ranges to ensure you get at least a certain version
> - once done figuring those out, it will either take the nearest
> (current), newest (not yet implemented), oldest (nyi), or fail if they
> don't match (nyi). Other techniques could be plugged in in future.
> - you can force a certain version to be used from the current POM.
>
> You might like to check out
> https://sydneyjug.dev.java.net/files/documents/922/15554/sjug20050601.pdf
> which talks about the new features. A newer version as presented at
> JavaOne/OSCon should be up soon.
>
>
>>It seems however that m2 is a lot less documented than m1 (is that
>>possible:) ) and m2 is far beyond from being complete.
>>Now that's where we go. Since I seem to like your ideas I wonder
>>if I could get involved a little (do not expect too much cause I
>>am already involved in another open-source project - that is of cause
>>using maven).
>>
>>Maybe you could help me out getting into m2 a little faster.
>
>
> We've done plenty of doco on the site about plugin development (the mojo
> API and the build lifecycle). It could be better, but combined with the
> current examples we hope its enough to get started.
>
> What we really need help with is:
> - documentation: http://maven.apache.org/maven2/docs-required.html
> - writing plugins:
> http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Matrix
>
>
>>I do not have a clue what the actual state of m2 is (are you still
>>planning important architectural decicisions or is everyting clear
>>and just some code missing :)).
>
>
> As Jason said, we are nearly feature complete and about to hit beta, so
> only plugin development and bugfixes from here on until about October
> when we will start on Maven 2.1 :)
>
>
>>BTW it seems that the POM inheritance in subprojects is not yet working
>>properly. I had to define things like folders (that src/main/java, ...
>>stuff) and specific settings (JDK 5.0 compliance, funny that it is still
>>-source 1.5 and not 5.0) in every subproject.
>
>
> This has been tested - so if you have a reproducible failure, please
> post it to JIRA.
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC7TtLmPuec2Dcv/8RAp2JAJ4srqYwgCm9fUHaTci3FBasKvpRQACfULN0
iwAHBzM2E+IHSxF2TZ+s+Cg=
=ABeY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] getting involved?
Posted by Trygve Laugstøl <tr...@codehaus.org>.
On Fri, Aug 05, 2005 at 03:13:49PM +0200, Thomas Van de Velde wrote:
> Hi Vincent,
>
> Thanks for your view on this. Just for the record, as you already know, I am
> a big fan of Maven and I will continue to use and promote Maven whether or
> not it uses Spring. ;-) I just want to dig a bit deeper in this discussion
> as it's something that's been on my mind for a while and I am not sure that
> it's been fully clarified yet. I am sure some other users may be asking the
> same question.
>
> (I've added a couple of comments below)
>
> On 8/5/05, Vincent Massol <vm...@pivolis.com> wrote:
> >
> > Hi Thomas,
> >
> > > -----Original Message-----
> > > From: Thomas Van de Velde [mailto:thomas.vdvelde@gmail.com]
> > > Sent: vendredi 5 août 2005 11:14
> > > To: Maven Developers List
> > > Subject: Re: [m2] getting involved?
> > >
> > > >
> > > > BTW - I like plexus. Haven't noticed the project before. I had used
> > > > avalon and had a look at pico+nano before. Plexus seems to be
> > powerfull
> > > > like avalon containers but less invasive (like the spring-framework).
> > > > Maybe I'll use that in my project. Would you again decide for plexus
> > if
> > > > you'd choose now?
> > >
> > >
> > > In what way would Spring be more invasive than Plexus? My issue with the
> > > Plexus container is that it is completely unknown to most developers,
> > that
> > > there are no books and hardly any documentation on the site. I assume
> > > there
> > > must be good reasons for starting yet another IoC container (Can
> > somebody
> > > elaborate on those reasons?)
> >
> > There are 2 viewpoints you need to consider:
> >
> > 1/ First viewpoint: As a Maven2 user or as a Maven2 plugin writer
> >
> > As a Maven user/plugin writer you don't have to care as it's transparent
> > for
> > you, even if you're writing plugins. So it's a non-issue.
>
>
> This makes sense to me. The philosophy of IoC and DI is to provide services
> around POJO's (let me correct; MOJO's ;-), it should be pretty transparent
> for the end user. Just wondering here if it would be usefull for users to
> profit from the tool support that comes with Spring (beandoc, Spring-IDE,
> ... and probably other stuff to come). Also, I think the out-of-box support
> for JMX would make sense for remote configuration of a Maven build server.
> You could also have a plugin that wants to profit from a persistence
> template to e.g. write results in a database, or Web Services to call a
> build target remotely.
As both a Maven and a Plexus developer I can say that adding JMX support
for Continuum[1] (the Maven CI server) will be trivial. There is already a
SOAP and a XMLRPC interface.
>
> 2/ Second viewpoint: As a Maven core developer.
> >
> > In that case, you're the one developing the solution and it's your call to
> > choose whatever technology you wish. The current Maven developers are
> > aware
> > of the other IOC containers but for now they have preferred to use their
> > own.
>
> Here we have a misunderstanding. My question is not meant as critisism. It's
> mearly a reflection that I am making. I think it's a fair question to ask.
> Since this hasn't been fully responded to on TSS, I ask again.
>
> I do agree with you that one drawback is its support. That said it does
> > also bring lots of advantages to them like the ability to quickly make
> > changes to it to support Maven2 use cases. I believe those advantages are
> > currently greater that the disadvantages.
>
>
> Fully agree. You, as a Maven developer, own all of the code so you can
> easily customize. So would Plexus be more a build-oriented IoC container?
No, Plexus is a truly generic container. It started out as a
implementation of the Avalon component API (which is still supports).
Plexus is used in several other applications (written by both us and
others), so it's not a build-oriented container, but it is true that we
have a lot of build-oriented tools and components :)
It is also possible for Plexus to add support for other component
lifecycles so if you really want to use your Spring beans in Plexus it
won't be a mountain of work. Let me know if you ever want to try.
> Conclusion: 99.9999% of all persons around Maven 2 are users and they don't
> > need to care as it's transparent for them.
>
>
> That's why I posted the question on the developers list ;-)
>
> -Vincent
> >
> > PS: This represents only my analysis of the situation. I'm not speaking
> > for
> > the m2 team although I believe they would agree with this :-)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> Would this be a correct conclusion?
>
> Plugin developers and M2 users, are not really exposed to Plexus. You can
> easily write your plugins without having to learn about another IoC
> container.
That's definitely a pretty good conclusion, but I have to add that there
might be cases where you might have to write Plexus components but we hope
to keep those cases to a minumum and that we can collect as much commonly
used code in shared components.
[1]: http://maven.apache.org/continuum
--
Trygve
Re: [m2] getting involved?
Posted by Thomas Van de Velde <th...@gmail.com>.
Hi Vincent,
Thanks for your view on this. Just for the record, as you already know, I am
a big fan of Maven and I will continue to use and promote Maven whether or
not it uses Spring. ;-) I just want to dig a bit deeper in this discussion
as it's something that's been on my mind for a while and I am not sure that
it's been fully clarified yet. I am sure some other users may be asking the
same question.
(I've added a couple of comments below)
On 8/5/05, Vincent Massol <vm...@pivolis.com> wrote:
>
> Hi Thomas,
>
> > -----Original Message-----
> > From: Thomas Van de Velde [mailto:thomas.vdvelde@gmail.com]
> > Sent: vendredi 5 août 2005 11:14
> > To: Maven Developers List
> > Subject: Re: [m2] getting involved?
> >
> > >
> > > BTW - I like plexus. Haven't noticed the project before. I had used
> > > avalon and had a look at pico+nano before. Plexus seems to be
> powerfull
> > > like avalon containers but less invasive (like the spring-framework).
> > > Maybe I'll use that in my project. Would you again decide for plexus
> if
> > > you'd choose now?
> >
> >
> > In what way would Spring be more invasive than Plexus? My issue with the
> > Plexus container is that it is completely unknown to most developers,
> that
> > there are no books and hardly any documentation on the site. I assume
> > there
> > must be good reasons for starting yet another IoC container (Can
> somebody
> > elaborate on those reasons?)
>
> There are 2 viewpoints you need to consider:
>
> 1/ First viewpoint: As a Maven2 user or as a Maven2 plugin writer
>
> As a Maven user/plugin writer you don't have to care as it's transparent
> for
> you, even if you're writing plugins. So it's a non-issue.
This makes sense to me. The philosophy of IoC and DI is to provide services
around POJO's (let me correct; MOJO's ;-), it should be pretty transparent
for the end user. Just wondering here if it would be usefull for users to
profit from the tool support that comes with Spring (beandoc, Spring-IDE,
... and probably other stuff to come). Also, I think the out-of-box support
for JMX would make sense for remote configuration of a Maven build server.
You could also have a plugin that wants to profit from a persistence
template to e.g. write results in a database, or Web Services to call a
build target remotely.
2/ Second viewpoint: As a Maven core developer.
>
> In that case, you're the one developing the solution and it's your call to
> choose whatever technology you wish. The current Maven developers are
> aware
> of the other IOC containers but for now they have preferred to use their
> own.
Here we have a misunderstanding. My question is not meant as critisism. It's
mearly a reflection that I am making. I think it's a fair question to ask.
Since this hasn't been fully responded to on TSS, I ask again.
I do agree with you that one drawback is its support. That said it does
> also bring lots of advantages to them like the ability to quickly make
> changes to it to support Maven2 use cases. I believe those advantages are
> currently greater that the disadvantages.
Fully agree. You, as a Maven developer, own all of the code so you can
easily customize. So would Plexus be more a build-oriented IoC container?
Conclusion: 99.9999% of all persons around Maven 2 are users and they don't
> need to care as it's transparent for them.
That's why I posted the question on the developers list ;-)
-Vincent
>
> PS: This represents only my analysis of the situation. I'm not speaking
> for
> the m2 team although I believe they would agree with this :-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Would this be a correct conclusion?
Plugin developers and M2 users, are not really exposed to Plexus. You can
easily write your plugins without having to learn about another IoC
container.
Cheers,
Thomas
Re: [m2] getting involved?
Posted by Thomas Van de Velde <th...@gmail.com>.
Thanks Kristian for this update. Not a very long discussion though ;-)
I believe that many of the features listed in this TSS thread are now
supported by Spring. Also, Spring adds JMX support to its IoC container. I
can imagine that this could be used e.g. to drop a Maven project in an
application server and dynamically configure your development environment.
That way you could have the option to profit from administration and
monitoring services provided by an application server. (I also believe that
Groovy and Beanshell scripting will be supported with Spring 1.3.)
I understand why the choice for Plexus has been made (at the time). But I
seriously wonder if it's the best call for the long run. The couple of
things that might be missing in Spring to support M2, could be added to
Spring. The big plus would be that
1) Maven users will be able to use their existing Spring knowledge for the
development of plugins, which also attracts a wider community.
2) Maven developers can focus on core activities and not on the low-level
IoC stuff.
Cheers,
Thomas
On 8/5/05, Kristian Nordal <kr...@gmail.com> wrote:
>
> On Aug 5, 2005, at 11:14 AM, Thomas Van de Velde wrote:
>
> >>
> >> BTW - I like plexus. Haven't noticed the project before. I had used
> >> avalon and had a look at pico+nano before. Plexus seems to be
> >> powerfull
> >> like avalon containers but less invasive (like the spring-framework).
> >> Maybe I'll use that in my project. Would you again decide for
> >> plexus if
> >> you'd choose now?
> >>
> >
> >
> > In what way would Spring be more invasive than Plexus? My issue
> > with the
> > Plexus container is that it is completely unknown to most
> > developers, that
> > there are no books and hardly any documentation on the site. I
> > assume there
> > must be good reasons for starting yet another IoC container (Can
> > somebody
> > elaborate on those reasons?)
>
> This was "discussed" a little bit in this thread:
> http://www.theserverside.com/news/thread.tss?thread_id=33219
>
> Regards
> Kristian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [m2] getting involved?
Posted by Kristian Nordal <kr...@gmail.com>.
On Aug 5, 2005, at 11:14 AM, Thomas Van de Velde wrote:
>>
>> BTW - I like plexus. Haven't noticed the project before. I had used
>> avalon and had a look at pico+nano before. Plexus seems to be
>> powerfull
>> like avalon containers but less invasive (like the spring-framework).
>> Maybe I'll use that in my project. Would you again decide for
>> plexus if
>> you'd choose now?
>>
>
>
> In what way would Spring be more invasive than Plexus? My issue
> with the
> Plexus container is that it is completely unknown to most
> developers, that
> there are no books and hardly any documentation on the site. I
> assume there
> must be good reasons for starting yet another IoC container (Can
> somebody
> elaborate on those reasons?)
This was "discussed" a little bit in this thread:
http://www.theserverside.com/news/thread.tss?thread_id=33219
Regards
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
IoC (was Re: [m2] getting involved?)
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Thomas,
Thomas Van de Velde wrote:
>>BTW - I like plexus. Haven't noticed the project before. I had used
>>avalon and had a look at pico+nano before. Plexus seems to be powerfull
>>like avalon containers but less invasive (like the spring-framework).
>>Maybe I'll use that in my project. Would you again decide for plexus if
>>you'd choose now?
>
>
>
> In what way would Spring be more invasive than Plexus?
None. That is what I was saying:
Plexuse seems to be less invasive than avalon. And shares this ability
with spring.
> My issue with the
> Plexus container is that it is completely unknown to most developers, that
> there are no books and hardly any documentation on the site. I assume there
> must be good reasons for starting yet another IoC container (Can somebody
> elaborate on those reasons?)
For me the reason was that the Avalon API is inacceptable for me because I
am bound to it. If I would later switch to spring or anything else, I would
need to rewrite a lot of my code. And the message on the avalon homepage
says a clear language. So I looked at spring and it seemed that it
solves that issue but on the other hand the bean-factory approach is a
little too low-level for me. I have to do way too much just to get
simple things done (e.g. injecting a component-specific logger) and the
configuration is xml but what you are doing is not configuration but
programming.
So besides I looked at various other solutions but havent found anything
acceptable so far. So I started my own Container.
As I pointed out in my mail: I found plexus and it looks good. There is
hardly no documentation and if you just start on the homepage of plexus
you will never even come to the point deciding to use it. Maybe I'll
drop my own container and switch to plexus - time will show.
But in may case the requirements for the container are so simple that it
might be easier to develop my own than understanding plexus :)
Anyways I started an experiment by writing some sort of API or better
specification for component "descriptoring" that could be understood by
any container-framework so components could be developed completely
container independent - for those who are interesed:
http://m-m-m.sourceforge.net/container/javadoc/
http://m-m-m.sourceforge.net/container/container.jar
I would love to hear comments from your point of view since you have
a lot more requirements for the container. So would you say that just
some things are missing in the suggested API or would you say that the
complete approach would be inacceptable for you / for plexus / for
whatever thing and reason.
Take care
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9RtvmPuec2Dcv/8RAskQAKCAO6qbi6nP4pLpMkVlRVImHF+CEACdHR7t
Sh+dq7eixO5g1g1IewMDUzA=
=2s+b
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [m2] getting involved?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Thomas,
> -----Original Message-----
> From: Thomas Van de Velde [mailto:thomas.vdvelde@gmail.com]
> Sent: vendredi 5 août 2005 11:14
> To: Maven Developers List
> Subject: Re: [m2] getting involved?
>
> >
> > BTW - I like plexus. Haven't noticed the project before. I had used
> > avalon and had a look at pico+nano before. Plexus seems to be powerfull
> > like avalon containers but less invasive (like the spring-framework).
> > Maybe I'll use that in my project. Would you again decide for plexus if
> > you'd choose now?
>
>
> In what way would Spring be more invasive than Plexus? My issue with the
> Plexus container is that it is completely unknown to most developers, that
> there are no books and hardly any documentation on the site. I assume
> there
> must be good reasons for starting yet another IoC container (Can somebody
> elaborate on those reasons?)
There are 2 viewpoints you need to consider:
1/ First viewpoint: As a Maven2 user or as a Maven2 plugin writer
As a Maven user/plugin writer you don't have to care as it's transparent for
you, even if you're writing plugins. So it's a non-issue.
2/ Second viewpoint: As a Maven core developer.
In that case, you're the one developing the solution and it's your call to
choose whatever technology you wish. The current Maven developers are aware
of the other IOC containers but for now they have preferred to use their
own. I do agree with you that one drawback is its support. That said it does
also bring lots of advantages to them like the ability to quickly make
changes to it to support Maven2 use cases. I believe those advantages are
currently greater that the disadvantages.
Conclusion: 99.9999% of all persons around Maven 2 are users and they don't
need to care as it's transparent for them.
-Vincent
PS: This represents only my analysis of the situation. I'm not speaking for
the m2 team although I believe they would agree with this :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [m2] getting involved?
Posted by Thomas Van de Velde <th...@gmail.com>.
>
> BTW - I like plexus. Haven't noticed the project before. I had used
> avalon and had a look at pico+nano before. Plexus seems to be powerfull
> like avalon containers but less invasive (like the spring-framework).
> Maybe I'll use that in my project. Would you again decide for plexus if
> you'd choose now?
In what way would Spring be more invasive than Plexus? My issue with the
Plexus container is that it is completely unknown to most developers, that
there are no books and hardly any documentation on the site. I assume there
must be good reasons for starting yet another IoC container (Can somebody
elaborate on those reasons?)
Re: [m2] getting involved?
Posted by Brett Porter <br...@apache.org>.
joerg wrote:
> I will check if I am on the latest version or better
> build m2 directly from svn. Maybe that is the reason why POM inheritance
> did not work for me. I'll check this and if it still does not work I'll
> send you the toplevel and a sub POM.
Thanks - it has seemed to work since alpha-1, though.
>
> I've seen on the plugin matrix that there will be no "MultiProject
> Plugin". Is that because you now have "Multi-Project" by design and not
> like some sort of late add-on so all plugins can support this directly?
Correct!
>
> BTW - I like plexus. Haven't noticed the project before. I had used
> avalon and had a look at pico+nano before. Plexus seems to be powerfull
> like avalon containers but less invasive (like the spring-framework).
> Maybe I'll use that in my project. Would you again decide for plexus if
> you'd choose now?
Actually, Jason started Plexus to be able to do the things m2 needed
that other containers couldn't.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org