Thanks, that's what I'm currently doing.I know eclipse update site plugins
feature and fragments have to be in the form ${artifactId}_${version}.jar,
so once I have a path to the resource in the local repo I copy it to the
update site with the correct final name.
Wb
On 9/6/06, John Casey <[EMAIL PROTECTED]> wrote:
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
> > >
> > >
> >
> >
>
>
