You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@zenplex.com> on 2003/04/16 21:04:28 UTC
ArtifactFactory component
Michal,
Do you know where to plug stuff in or would you like me to make a stub
component that you can work from?
I'm just getting all the components configured and running from a test
which can now be used to try out different implementations of
components.
Just let me know what you need so you can carry on.
--
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: ArtifactFactory component
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-04-16 at 15:37, Michal Maczka wrote:
> Jason
> I have a bunch of question!
>
> I want to propose the following interface for ArtifactFactory
>
>
> public interface ArtifactFactory
> {
>
> List getArtifacts(Project project)
> }
>
Sure
>
> then the impementataion of this interface will also implements interfaces
> required by contracts you will define for Plexus component.
>
>
> I see two things that this class can do in one pass:
>
> a) Create the list (I am returing it)
> b) Build DependecyClassPath
>
I would like to keep those two operations separate. Even if the
components are very small the simple fact that the name of the component
describes what they are doing seems like a better idea to me.
>
> In my sketch of solution I have made the process of building depenecy list
> depenend on configuration settings.
>
> I called this TypeDescriptor.
>
> The List of of all known type descriptors were build from configuaration
> file.
> (I had 3 of them: main in Maven conf, one in ${user.dir} and third defined
> per
> project.
We probably want some default that we can maintain and allow some form
of extension for projects.
> Now I think that is too much. Probably mainn one + per project will do.
> I want to start with something simple and then eventually if you and the
> others
> will like the way in which I am tring to do this add more things.
> So I want to have just one configuration file.
>
> I was thinking about adding it to Plexus conf first.
> Now I am rather willing to make direct XML parsing.
I'm sure we'll figure out what's best. You can use the Avalon
configuration stuff or you can make a little parser. I would like to
stick with the xmlpull stuff though. It's small and fast and has few
dependencies. You can put the descriptor in a separate file and still
use the Avalon configuration method. It doesn't have to be included in
the plexus.conf file.
>
>
> Point b) is bit more controvrrsial.
> The advanatge is the it will be faster.
>
> I also think that those two things: Dependecy Path + Artifact List
> should be kept in POM (Project class) as POM probably should be only object
> passed between "nodes" of the workflow. From Project you have acess to
> Maven(Session)
> so if you have those two other things there will be propbaly enough
I agree. Currently these two things are stored in the POM.
>
> Disadvatange of b) is that too many things will be happeing in one step
> and if you want to have something like group depenecy the things will be
> getting more complex but still I don't see a serious reasons to make it in
> two distincs steps.
> Also think that resolutions of jar overring should happen in artifact
> factory.
I agree, this is what's happening in the ArtifactListBuilder currently.
Any possible transformations from dep --> artifact should be taken care
of the in the factory you're making.
> So as a result of ArtifactFactory the two attributes of POM
> will change:
>
> Artifact List (kept as java.util.List) and DependecyCLasspath (kept as
> String)
They are already there :-)
> In first shoot I just want to port old implementation to have the concept
> proof
> and next the cofigurable ArtifactFactory can be developed.
> And there is a lot of other open points...
>
> I think that is it safer to make such smaller steps than one mortal step.
>
>
> If I can also propose something in addition: will you consider to rename in
> future
> "jar override" to "artifact override" and consequently
>
> replace <jar> tag with something else in POM?
Again I agree, we need to work with artifacts generally. The naming is a
result of initially only supporting JAR artifacts.
>
> What you think? Is this reasonable
Sounds good. Just throw more questions at me and I'll try to answer
them. I'll integrate whatever you have into the new code whenever you
have a chance. I'm eager to have someone else making some components for
the final 1.0.
> Michal
>
> > Just let me know what you need so you can carry on.
> >
> > --
> > 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
> >
> >
> > ----------------------------------------------------------------------
> > Ponad 100 tysiecy facetow szukajacych przyjaciolki, kochanki, zony,
> > dziewczyny... Czekamy! >>> http://link.interia.pl/f170e
> >
> >
> >
>
>
> ----------------------------------------------------------------------
> Ponad 100 tysiecy facetow szukajacych przyjaciolki, kochanki, zony,
> dziewczyny... Czekamy! >>> http://link.interia.pl/f170e
>
>
>
> ---------------------------------------------------------------------
> 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: ArtifactFactory component
Posted by Michal Maczka <mm...@interia.pl>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jason@zenplex.com]
> Sent: Wednesday, April 16, 2003 9:04 PM
> To: Maven Developers List
> Subject: ArtifactFactory component
>
>
> Michal,
>
> Do you know where to plug stuff in or would you like me to make a stub
> component that you can work from?
>
> I'm just getting all the components configured and running from a test
> which can now be used to try out different implementations of
> components.
>
Jason
I have a bunch of question!
I want to propose the following interface for ArtifactFactory
public interface ArtifactFactory
{
List getArtifacts(Project project)
}
then the impementataion of this interface will also implements interfaces
required by contracts you will define for Plexus component.
I see two things that this class can do in one pass:
a) Create the list (I am returing it)
b) Build DependecyClassPath
In my sketch of solution I have made the process of building depenecy list
depenend on configuration settings.
I called this TypeDescriptor.
The List of of all known type descriptors were build from configuaration
file.
(I had 3 of them: main in Maven conf, one in ${user.dir} and third defined
per
project.
Now I think that is too much. Probably mainn one + per project will do.
I want to start with something simple and then eventually if you and the
others
will like the way in which I am tring to do this add more things.
So I want to have just one configuration file.
I was thinking about adding it to Plexus conf first.
Now I am rather willing to make direct XML parsing.
Point b) is bit more controvrrsial.
The advanatge is the it will be faster.
I also think that those two things: Dependecy Path + Artifact List
should be kept in POM (Project class) as POM probably should be only object
passed between "nodes" of the workflow. From Project you have acess to
Maven(Session)
so if you have those two other things there will be propbaly enough
Disadvatange of b) is that too many things will be happeing in one step
and if you want to have something like group depenecy the things will be
getting more complex but still I don't see a serious reasons to make it in
two distincs steps.
Also think that resolutions of jar overring should happen in artifact
factory.
So as a result of ArtifactFactory the two attributes of POM
will change:
Artifact List (kept as java.util.List) and DependecyCLasspath (kept as
String)
In first shoot I just want to port old implementation to have the concept
proof
and next the cofigurable ArtifactFactory can be developed.
And there is a lot of other open points...
I think that is it safer to make such smaller steps than one mortal step.
If I can also propose something in addition: will you consider to rename in
future
"jar override" to "artifact override" and consequently
replace <jar> tag with something else in POM?
What you think? Is this reasonable
Michal
> Just let me know what you need so you can carry on.
>
> --
> 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
>
>
> ----------------------------------------------------------------------
> Ponad 100 tysiecy facetow szukajacych przyjaciolki, kochanki, zony,
> dziewczyny... Czekamy! >>> http://link.interia.pl/f170e
>
>
>
----------------------------------------------------------------------
Ponad 100 tysiecy facetow szukajacych przyjaciolki, kochanki, zony,
dziewczyny... Czekamy! >>> http://link.interia.pl/f170e
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org