Why isn't used when installing/deploying?

[Wendell Beckwith <wb...@gmail.com>]

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

Re: Why isn't used when installing/deploying?

[Wendell Beckwith <wb...@gmail.com>]

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 <ca...@gmail.com> 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 <wb...@gmail.com> 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 <ca...@gmail.com> 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 <wb...@gmail.com> 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Re: Why isn't used when installing/deploying?

[John Casey <ca...@gmail.com>]

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 <wb...@gmail.com> 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 <ca...@gmail.com> 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 <wb...@gmail.com> 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
> > >
> > >
> >
> >
>
>

Re: Why isn't used when installing/deploying?

[Wendell Beckwith <wb...@gmail.com>]

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 <ca...@gmail.com> 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 <wb...@gmail.com> 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
> >
> >
>
>

Re: Why isn't used when installing/deploying?

[John Casey <ca...@gmail.com>]

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 <wb...@gmail.com> 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
>
>