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/05/01 20:55:03 UTC
[maven-new ] ArtifactProcessor - What I am doing + questions.
FYI:
To show big picture of what I am trying to do in Maven-New.
My changes are mainly dedicated to allow generic artifact processing in
Maven.
But as in the same time Maven code is being clean-up , reorganized and
decomposed into
components (Avalon Components) sometimes there are some other changes
needed.
I see processing of artifacts as follows:
(this will be defined in class: <<ArtifactProcessor>> which will replace
<<ArrtifactListProcessor>>):
1. <<ArtifactFactory>> creates list of artifacts for project.
"to create" artifact actually means to convert information kept in
dependency to a path (file).
<<ArtifactFactory>> is using the service <<RepositoryLayout>> for this
purpose.
<<RepositoryLayout>> (ore more precisely <<DefaultRepositoryLayout>>)
is type-sensitive and for different artifact types in can returns different
paths.
The mapping between type and layout is defined in properties file:
core/src/conf/layout.properties.
I see the possibility of defining layout per type as very powerful and
dangerous weapon.
So I am 99% sure that this facility should be used only internally and very
carefully.
Some more comments (examples) you can find in layout.properties file.
2. In this step the functionality currently defined in <<DependecyVerifier>>
class
will be executed.
Here I have a proposition:
I want to create a new interface: <<ArtifactDownloader>> and move some of
the code from <<DependecyVerifier>>
to this class (as I believe it will be easier to understand what is
happening where).
QUESTION #1: Do you agree with this and can I add <<ArtifactDownloader>>
interface ?
public interface ArtifactDownloader
{
public boolean getRemoteArtifact(Artifact artifact, Project project);
}
3. Once we are sure we have all necessary artifacts -
for each artifact we will apply associated artifact handler (if any)
The mapping between type and <<ArtifactHandler>> is defined in
core/src/conf/layout.properties
<<ArtifactHandler>> is new addition and exposes such method:
void process(Artifact artifact, Project project);
To make it yet more powerful probably better would be:
void process(Artifact artifact, Project project,ServiceManager
serviceManager);
As example of functionality covered by <<ArtifactHandler>>
I can give <<JarHandler>> which, will add an entry to Project's
dependecyClasspath
(QUESTION#2: Jason are you sure we have a such field in Project.java. Just
cannot see..)
If not - is it OK I will add it?
regards
Michal
----------------------------------------------------------------------
Dla tych, co sie cenia... >>> http://link.interia.pl/f1713
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [maven-new ] ArtifactProcessor - What I am doing + questions.
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Fri, 2003-05-02 at 21:33, Michal Maczka wrote:
> > -----Original Message-----
> > From: Mark H. Wilkinson [mailto:mhw-maven-dev@kremvax.net]
> >
> > Hmm; neat! Is there an assumption here that an artifact is a single file
> > in the filesystem?
>
> Yes. There is an assumption that artifact is a single file.
> For the moment there is even one more restrictive assumption - we have one
> artifact per dependency.
>
> I am also looking forward to make scenario you described a reality.
Cool.
> > Also, would it be possible to have different physical representations
> > for an artifact? I'm thinking specifically about modeling projects in
> > the filesystem as artifacts to infer inter-project dependencies.
>
> I know what you mean.. but I disagree with such vision
> For "hacking on continuously" TogetherJ, Eclipse, IDEA or something similar
> (IDE)
> are much more appropriate tools.
I agree completely. I'm actually more interested in making sure that
maven has enough information to completely generate the project files
that TogetherJ, Eclipse, IDEA and such like require in order to work on
a source tree.
In the past, projects I've worked on have (more-or-less) required
everyone to use the same development environment and we've version
controlled the files that the tools use to describe each project (for
example, the .project and .classpath files that Eclipse uses, or the
blah.jpx file that JBuilder uses). We've also had a parallel Ant build
system that is used to produce deployable artifacts, but often the Ant
build system isn't quite up-to-date because people aren't maintaining
both the IDE and the Ant description of the project.
I'd really like maven's internal project model to include enough
information to allow all this stuff to be generated, so it doesn't
matter whether everyone is using the same tools (as long as they're
using maven ;-) ). I'd like to be able to download the sources for a
number of projects, explain to maven that I've got these things
installed locally and then be able to run 'maven eclipse' in each source
tree and have the whole lot working in Eclipse just as though I'd set
each project up by hand. For open-source projects where you can't really
mandate that people use a particular IDE, I'd have thought this would be
pretty compelling. And for commercial shops it'd be beneficial because
you're maintaining one description of the build system (maven) rather
than two (Ant and the IDE).
To do that I think maven needs to know whether the user wants a
dependency to refer to a local copy of the project source tree, or to a
jar file in the repository. I'm just not sure how this information is
best represented, though.
-Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [maven-new ] ArtifactProcessor - What I am doing + questions.
Posted by Michal Maczka <mm...@interia.pl>.
> -----Original Message-----
> From: Mark H. Wilkinson [mailto:mhw-maven-dev@kremvax.net]
> Sent: Friday, May 02, 2003 6:58 PM
> To: Maven Developers List
> Subject: Re: [maven-new ] ArtifactProcessor - What I am doing +
> questions.
>
>
> On Thu, 2003-05-01 at 19:55, Michal Maczka wrote:
> >
> > 1. <<ArtifactFactory>> creates list of artifacts for project.
> > "to create" artifact actually means to convert information kept in
> > dependency to a path (file).
> > <<ArtifactFactory>> is using the service <<RepositoryLayout>> for this
> > purpose.
> > <<RepositoryLayout>> (ore more precisely <<DefaultRepositoryLayout>>)
> > is type-sensitive and for different artifact types in can
> returns different
> > paths.
> > The mapping between type and layout is defined in properties file:
> > core/src/conf/layout.properties.
>
> Hmm; neat! Is there an assumption here that an artifact is a single file
> in the filesystem? Would a JSP tag library be described as two artifacts
> (a jar file and the tag library descriptor), or could we get this down
> to a single artifact (and hence a single dependency) that describes two
> related files.
>
Yes. There is an assumption that artifact is a single file.
For the moment there is even one more restrictive assumption - we have one
artifact per dependency.
I am also looking forward to make scenario you described a reality.
I hope that interfaces are open enough to enable it
somewhere ... in one of the next iterations
I have duplicated some code of Dependency in Artifact.
This means simpler jelly scripting:
instead of
${artifact.dependecy.artifactId}
the code can look:
${artifact.groupId}
That's already some reason .. but making this change I was thinking about
breaking the rule:
one dependency - one artifact which possibly can happen in future.
There are two important things which should be addressed in the future.
"transitive dependency" and "group dependency".
I am dreaming about such scenario:
<dependency>
<groupId>struts</groupId>
<artifactId>struts</artifactId>
<version>2.0</version>
<type>group</type>
<kind>runtime</kind>
<transitive>true</transitive>
<properties>
<war.bundle>true</war.bundle>
</properties>
<dependency>
and all the artifacts delivered by struts are bundled in your war (this is
"group dependency")
In addition, as Struts itself has a lot of dependencies, those dependices
will be also bundled in
your war (this is transitive dependency).
I hope that very soon those things will be technically possible.
But then before implementing them we must clearly define what those terms
actualy mean.
For example for transitive dependencies I suppose that POM already has all
sufficient data.
> Also, would it be possible to have different physical representations
> for an artifact? I'm thinking specifically about modeling projects in
> the filesystem as artifacts to infer inter-project dependencies. Or, in
> other words, if you have a project that's pretty stable it makes sense
> to do a 'maven jar:install' to compile it and put a copy of the
> resulting jar file in the repository. If you have a project that you're
> hacking on continuously, though, you'd probably prefer dependent
> projects to build directly against the target/classes directory in the
> project source tree. So you could do something like
> 'maven project:install' to place some information into the repository to
> tell maven where the project is. Then the artifact that satisfies a
> dependency has a different physical representation (a directory rather
> than a jar file).
>
I know what you mean.. but I disagree with such vision
For "hacking on continuously" TogetherJ, Eclipse, IDEA or something similar
(IDE)
are much more appropriate tools. Jason almost managed (the code is very
close to it)
to made Maven embeddable in such tools (as it is already a case with ANT).
I personally hate when people are using "command prompt" as only working
environment.
In my opinion this is huge waste of time (yes I do hate VI ;) ) and don't
think that
Maven has to support such practices. Sure it can... but just don't know why.
Michal
----------------------------------------------------------------------
Dla tych, co sie cenia... >>> http://link.interia.pl/f1713
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [maven-new ] ArtifactProcessor - What I am doing + questions.
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Thu, 2003-05-01 at 19:55, Michal Maczka wrote:
>
> 1. <<ArtifactFactory>> creates list of artifacts for project.
> "to create" artifact actually means to convert information kept in
> dependency to a path (file).
> <<ArtifactFactory>> is using the service <<RepositoryLayout>> for this
> purpose.
> <<RepositoryLayout>> (ore more precisely <<DefaultRepositoryLayout>>)
> is type-sensitive and for different artifact types in can returns different
> paths.
> The mapping between type and layout is defined in properties file:
> core/src/conf/layout.properties.
Hmm; neat! Is there an assumption here that an artifact is a single file
in the filesystem? Would a JSP tag library be described as two artifacts
(a jar file and the tag library descriptor), or could we get this down
to a single artifact (and hence a single dependency) that describes two
related files.
Also, would it be possible to have different physical representations
for an artifact? I'm thinking specifically about modelling projects in
the filesystem as artifacts to infer inter-project dependencies. Or, in
other words, if you have a project that's pretty stable it makes sense
to do a 'maven jar:install' to compile it and put a copy of the
resulting jar file in the repository. If you have a project that you're
hacking on continuously, though, you'd probably prefer dependent
projects to build directly against the target/classes directory in the
project source tree. So you could do something like
'maven project:install' to place some information into the repository to
tell maven where the project is. Then the artifact that satisfies a
dependency has a different physical representation (a directory rather
than a jar file).
-Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org