Where the finalName is important in the filename, I think the only
alternative is to copy (ugh, I know) the file inside ${
project.build.directory} with the appropriate name, and reference that file.
-john
On 9/6/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
OK, I'll buy that. I really don't care what the name is in the repo,
local
or remote. With that being said, what is the correct way to get the
artifact back out of the repo, again local and remote, where the artifact
is
named as the <finalName> element in the artifact's pom? I might have just
used the wrong example code to learn from, but I basically create an
Artifact with the groupId, artifactId and version, then ask the
ArtifactRepository for the path of the artifact, combine that with the
local
repo basedir and I can build a path off of it. Should I not be doing that
or do I need to go the extra step to grab the final name from the
deployed
pom file?
Wb
On 9/6/06, John Casey <[EMAIL PROTECTED]> wrote:
>
> The way Maven 2 was designed, the repository system is meant to be sort
of
> opaque to outside systems (at least, that's the result of the design).
The
> finalName was meant to be used when exposing artifacts (either from the
> repository, or freshly-built) to the outside world, generally by using a
> maven plugin to do so.
>
> As an example, where the maven binary assembly artifact might exist in
the
> repository as: maven-core-2.0.4-bin.tar.gz, when used as a constituent
of
> another assembly, it would land in the maven-2.0.4 directory (I think,
> can't
> remember the exact finalName on that one). So, the plugins are
responsible
> for resolving an artifact from the repository (which could be in any
> format,
> even a database), and presenting it to the outside world for consumption
> with the correct filename.
>
> I'm sure that's not convenient in all cases, and might present some
> complication associated with creating a mapping facade for the remote
> repository artifacts, but this is currently the only way Maven can keep
> track of what's in that repository without introducing ambiguity or
> unreasonable performance penalties. Maybe it'll change for 2.x, but
there
> are no plans to do so right now.
>
> Does that help?
>
> -john
>
> On 9/2/06, Wendell Beckwith <[EMAIL PROTECTED]> wrote:
> >
> > I am working on creating a plugin to specifically do Eclipse plugin
> builds
> > and OSGi bundles as a consequence that all plugins are bundles. I
have
> > run
> > into a problem where some parts of eclipse doesn't care what the name
of
> a
> > jar file is as long as it's contents is correct. Then there is the
> > Eclipse
> > Update Manager which takes the plugin identifier (artifactId) and
> version
> > (versionId) and expects to download a file of
> > "plugins/${artifactId}_${version}.jar. I can set the <finalName>
> element
> > in
> > my pom to be <finalName>${artifactId}_${version}</finalName> but only
> the
> > jar produced in my project's target folder is named correctly. What
> gets
> > installed/deployed to the repo is the typical ${artifactId}-${version}
> > format. What is the logic of having a final name that is only local
to
> > me?
> >
> > Wb
> >
> >
>
>
