You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by dv...@clever-age.com on 2003/04/15 19:23:26 UTC
[Maven new] Some first comments
Re Jason,
I reviewed the Plexus and maven-new code. First it seems, you did not yet
makeit run, almost you did not run it inside plexus. Am i wrong?? But here are my
comments:
General:
* Could you take the Avalon convention to prefix all the class attributes
with an "m_" meaning "members" ??? That would be great for readability and
coherence with the Avalon project!!
For Plexus:
* Seems that you recreate lots of what Fortress does... The only difference I
see is about the service role/implementation relationship that is in fact
morestrict in Fortress as implementation must be identifiable by a Java class.
Youonly need a different role configuration and component factory in order to be
able to have Jython and al. components... Did you consider using Fortress
and ifyes, do you know what features Plexus (except the component repository) will
offer compared to Fortress ??
For Maven:
* For the PomInheritanceAspect, it looks like you will have to recreate the
Method object corresponding to the called method as AspectJ do not provide
direct access to the Method object but only the method name and argument
types.
Just consider the same aspect using Concern (ad ;)) :
public class PomInheritanceAspect
implements Aspect, Serviceable, Initializable, Startable
{
public void service(ServiceManager serviceManager) throws
ServiceException {
m_pointcutManager = (PointcutManager)
serviceManager.lookup(PointcutManager.ROLE); }
private PointcutManager m_pointcutManager;
public void initialize() throws Exception
{
m_projectGetters =
m_pointcutManager.get("*
org.apache.maven.project.Project.get*(..)"); }
Pointcut m_projectGetters;
Advice m_processInheritance = new Advice()
{
public Aspect getAspect() { return PomInheritanceAspect.this; }
public Object process(JoinPoint joinPoint, Object target, Object[]
arguments) {
// Let's grab the value that would normally be returned.
Object o = joinPoint.process(target, arguments);
// If the value is not defined and this project has a parent then
// we will try to retrieve the value from the parent.
if ( o == null && ((Project) joinPoint.getTarget()).hasParent() )
{
Project parentProject =
((Project) joinPoint.getTarget()).getParent();
return joinPoint.getMethod()
.invoke(parentProject, Object[] arguments);
}
return o;
}
}
public void start() throws Exception
{
m_projectGetters.addAroundAdvice(m_processInheritance);
}
public void stop() throws Exception
{
m_projectGetters.removeAdvice(m_processInheritance);
}
}
However you will have to recreate a method name for the
PomInterpolationAspectas you told you do not want to use Jexl anymore. Am i wrong ???
* Empty hooks for build:start and build:stop... This is COOL!!!
* Should you not define project-specific driver variables in a specific jelly
file that would set those values on the project context and not the base
context. If you do this like it, i think you will run in some same
problems asnow...
* CLI, I18N, and Avalon... I though that Avalon CLI will be deprecated in
favorof commons-cli. I know you want it to be agile, but...
* About Maven and DefaultMaven.
- Why getRootProject() is called getRootProject and not getProject ???
Does this mean that (1) (as there is setProject(..)) that a single pom implies
not only a project object but a hierarchy of them, (2) it is
mis-named, (3) one can change the project being processed for a sub-project ??? Just to
figure out to you it is confusing!
- I think you should separate the goal list management and resolution
in an other class. That is separating the static pom/options setting aspect
from the goals resolution session aspect.
I don't if you have worked on it again since you made your commit, but i will
try to make it run tonight and maybe start to work on it. Either write tests,
experiment plugin support or something like this. Tell me if it is okay.
BTW did you start with some thoughts about the plugin model ???
Again, let me say it is a great job!!!
Thanks. A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Maven new] Some first comments
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-04-15 at 13:23, dvillevalois@clever-age.com wrote:
> Re Jason,
>
> I reviewed the Plexus and maven-new code. First it seems, you did not yet
> makeit run, almost you did not run it inside plexus. Am i wrong?? But here are my
> comments:
As I said in IRC this is a work in progress. I put it in because people
kept asking to see it. It is not finished. Be patient.
> General:
>
> * Could you take the Avalon convention to prefix all the class attributes
> with an "m_" meaning "members" ??? That would be great for readability and
> coherence with the Avalon project!!
Absolutely not. I hate that convention, have never used it in Turbine,
Plexus and it won't be used in Maven.
> For Plexus:
>
> * Seems that you recreate lots of what Fortress does... The only difference I
> see is about the service role/implementation relationship that is in fact
> morestrict in Fortress as implementation must be identifiable by a Java class.
> Youonly need a different role configuration and component factory in order to be
> able to have Jython and al. components... Did you consider using Fortress
Yes, I did.
> and ifyes, do you know what features Plexus (except the component repository) will
> offer compared to Fortress ??
We have five, and now moving up to six people who know the code very
well. People who are involved in Maven and Plexus, there is the Maven
build and the set of tools in the form of the Plexus plugin. I tried
using Fortress many months ago and it didn't go very well for me even
though Peter Royal put in a lot of effort to get me going.
As there were virtually no docs, the build didn't work and getting help
proved difficult someone like myself just takes matter into their own
hands. When the codebase and docs are like that it's just as easy for me
to write something from scratch because it's just as easy. And this has
proven to be the case. Plexus can handle more than the Avalon API as
well. The Avalon API will be one of the APIs supported and AspectJ will
be tightly integrated.
We will be using Plexus and that decision won't change. There are
several other factors why we chose to create another container but as I
have given my word to the board to keep my mouth shut when I don't have
anything nice to say I will just leave it at that.
> For Maven:
>
> * For the PomInheritanceAspect, it looks like you will have to recreate the
> Method object corresponding to the called method as AspectJ do not provide
> direct access to the Method object but only the method name and argument
> types.
> Just consider the same aspect using Concern (ad ;)) :
Again, not a chance.
I have kept contact with some AspectJ folks off and on for a while and I
believe it is only AOP solution worth persuing. A whole raft of AOP
frameworks have cropped up and I've looked at a lot of them. I know
what's coming down the pipe with AspectJ and I don't honestly believe
anyone will come up with a better solution than Gregor Kiczales, Jim
Hugunin, and the rest of the AspectJ folks. They don't have some of the
flashy features but there is a huge community there and they have proven
that they take user needs into consideration as proven by the changes in
the up coming 1.1 release. There are many things I would like and I can
contribute toward seeing them come to fruition in AspectJ. My particular
viewpoint, one not shared by all, is that every other AOP framework is a
waste of time.
> * Empty hooks for build:start and build:stop... This is COOL!!!
Yah, those actually worked at one point. When I did the second
refactoring I had to disable them.
> * Should you not define project-specific driver variables in a specific jelly
> file that would set those values on the project context and not the base
> context. If you do this like it, i think you will run in some same
> problems asnow...
Jelly will simply be an execution environment and have nothing to do
with the core. The driver.jelly and driver.properties will go away. The
goop in driver.jelly will be written in Java and the driver.properties
will be defaults somewhere that can now be easily overridden. To take
into consideration share usage and some other use cases that have
cropped up.
> * CLI, I18N, and Avalon... I though that Avalon CLI will be deprecated in
> favorof commons-cli. I know you want it to be agile, but...
Yah, commons-cli will be used.
> * About Maven and DefaultMaven.
>
> - Why getRootProject() is called getRootProject and not getProject ???
> Does this mean that (1) (as there is setProject(..)) that a single pom implies
> not only a project object but a hierarchy of them, (2) it is
> mis-named, (3) one can change the project being processed for a sub-project ??? Just to
> figure out to you it is confusing!
>
> - I think you should separate the goal list management and resolution
> in an other class. That is separating the static pom/options setting aspect
> from the goals resolution session aspect.
That particular contract will more than likely get the most scrutiny as
it will be the point of contact for all client code. Lots of things will
get cleaned up as I get some time and more people take a peek and make
suggestions and make fixes themselves.
> I don't if you have worked on it again since you made your commit, but i will
> try to make it run tonight and maybe start to work on it. Either write tests,
> experiment plugin support or something like this. Tell me if it is okay.
> BTW did you start with some thoughts about the plugin model ???
I'm more interested in writing the plexus test cases right now. Getting
it to run really isn't a problem with the plexus plugin.
> Again, let me say it is a great job!!!
It will come along eventually.
> Thanks. A+. Didier.
>
>
>
> ---------------------------------------------------------------------
> 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: [Maven new] Some first comments
Posted by Didier Villevalois <dv...@clever-age.com>.
Hi Dion,
dion@multitask.com.au wrote:
>At the risk of starting a flame war. Yuck, please no!
>
Okay, this was just a suggestion. Let us not talk about that anymore ;)
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Maven new] Some first comments
Posted by di...@multitask.com.au.
<dv...@clever-age.com> wrote on 16/04/2003 03:23:26 AM:
> Re Jason,
>
> I reviewed the Plexus and maven-new code. First it seems, you did not
yet
> makeit run, almost you did not run it inside plexus. Am i wrong?? But
> here are my
> comments:
>
> General:
>
> * Could you take the Avalon convention to prefix all the class
attributes
> with an "m_" meaning "members" ??? That would be great for readability
and
> coherence with the Avalon project!!
At the risk of starting a flame war. Yuck, please no!
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org