Re: javafx-maven-plugin seems to ignore finalName parameter
Hi Uwe,
The javafx-maven-plugin is not a core Maven plugin, nor a Mojohaus one, so
you are probably better off filing an issue in the repository (
https://github.com/javafx-maven-plugin/javafx-maven-plugin/issues). I am
not sure whether FibreFoX even subscribes to this mailing list, and he
would be the best person to answer you.
Regards,
Curtis
--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
On Thu, Apr 27, 2017 at 8:23 AM, Uwe <uwe.ander...@amsde.com> wrote:
> I want the javafx-maven-plugin to create a jar file but without the version
> number in the file name.
> So I added
> ${project.artifactId}
> to the configuration section but the plugin seems to ignore that.
> What is wrong?
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/javafx-maven-plugin-seems-to-ignore-finalName-parameter-tp5907231.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
javafx-maven-plugin seems to ignore finalName parameter
I want the javafx-maven-plugin to create a jar file but without the version
number in the file name.
So I added
${project.artifactId}
to the configuration section but the plugin seems to ignore that.
What is wrong?
--
View this message in context:
http://maven.40175.n5.nabble.com/javafx-maven-plugin-seems-to-ignore-finalName-parameter-tp5907231.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
WAR plugin versus archiveClasses versus finalName
Folks,
Environment: Maven 3.1.1, JDK 1.7.0_45
I'm having some challenges with the Maven WAR plugin (2.4),
archiveClasses, and finalName. In addition, I am using the Freemarker
preprocessor plugin (FMPP plugin) to generate some output.
Here's what I've tried (without the FMPP plugin).
1. Default name (artifactId-version.extension)
All resources and classes get placed into artifactId-version.JAR as
expected. The WAR file is also named artifactId-version.WAR.
2. finalName as ${project.artifactId}
No classes get placed into artifactId-version.JAR. Resources are added
into artifactId-version.JAR. The WAR file is named artifactId.war
3. finalName as ${project.artifactId} with explicit outputFileMapping
outputFileNameMapping
@{artifactId}@-@{version}@.@{extension}@
/outputFileNameMapping
No classes get placed into artifactId-version.JAR. Resources are added
into artifactId-version.JAR. The WAR file is named artifactId.war
4. finalName as ${project.artifactId} with explicit outputFileMapping
outputFileNameMapping
@{artifactId}@.@{version}@.@{extension}@
/outputFileNameMapping
Note the '.' instead of the dash between artifactId and version.
All resources and classes are placed into artifactId.version.JAR. All
other dependent JARs are also renamed. The WAR file is named artifactId.war
To add confusion to the mix, I'm using the FMPP plugin. I've bound this
to the compile phase (rather than the default generate-sources phase),
and placed the output in target/classes. I'm doing this since I am
preprocessing some files that should get included into the JAR.
Now, if I rerun the above four scenarios, I get the following results.
1. The preprocessed file is not placed in the JAR file, even though it's
in target/classes in the proper place.
2. Only the resources get placed into the JAR file (as before).
3. Only the resources get placed into the JAR file (as before).
4. All resources, preprocessed files, and classes get placed into the
JAR file.
In short, scenario 4 works with the downside that it renames all other
dependent JARs to fit the outputFileNameMapping designation.
I don't understand why 3 doesn't work.
The desired end result is to have a version-less WAR file, and all of
the project resources bundled up into the standard
artifactId-version.extension naming format.
The only way I've found to accomplish this is to make a module with the
resources / source code and have the parent depend on this module. That
certainly feels like a hack to get around a packaging problem.
What is my vision problem (other than my requirements, which are sadly
not subject to change at the moment)?
Thanks,
Mark
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: WAR plugin versus archiveClasses versus finalName
The only way I've found to accomplish this is to make a module with the resources / source code and have the parent depend on this module. That certainly feels like a hack to get around a packaging problem. To me, this is not a hack. Maven does not really want you to have source code in WAR projects. The problems you are experiencing are related to that. You should move the source code to JAR projects and depend on them. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with property substitution into finalName
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates jars
using the substituted value, e.g. org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as
the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
Thanks Stephen,
I'm trying to figure out why I'm not seeing this in the actual staged artifacts,
or in previous releases.
Here's what I've concluded:
The maven-gpg-plugin has a bug - it copies the pom.xml to the finalname.pom, in
target, and then signs that, without substituting into the property variable in
the finalname. So, if you look into /target, it's got the wrong name.
But, when the install plugin installs, it
(a) ignores the incorrectly named ...pom in the /target, and instead, copies
the original pom to the install spot. You can see that in the run output for
the install step:
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\pom.xml to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\
uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom
(b) it does copy the incorrectly named .asc file to the repository, but
(SURPRISE !) it fixes up the name in the target :-) :
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\target\org.apache.uima.textmarker.engine_${parsedVersion
.osgiVersion}.pom.asc to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom.asc
So, we're only seeing this issue due to the fact that we happened to look into
the /target directory.
-Marshall
On 2/8/2013 12:33 PM, Stephen Connolly wrote:
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as
the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
On Friday, 8 February 2013, Marshall Schor wrote:
Thanks Stephen,
I'm trying to figure out why I'm not seeing this in the actual staged
artifacts,
or in previous releases.
Here's what I've concluded:
The maven-gpg-plugin has a bug - it copies the pom.xml to the
finalname.pom, in
target, and then signs that, without substituting into the property
variable in
the finalname. So, if you look into /target, it's got the wrong name.
But, when the install plugin installs, it
(a) ignores the incorrectly named ...pom in the /target, and instead,
copies
the original pom to the install spot. You can see that in the run output
for
the install step:
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\pom.xml
to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\
uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom
(b) it does copy the incorrectly named .asc file to the repository, but
(SURPRISE !) it fixes up the name in the target :-) :
The act of deploying standardises the names to the repository format. In a
sense finalName is an irrelevant distraction from Maven's point of view.
All it cares about is getting the artifact into the remote repository with
a name corresponding to the GAVCT coordinates
As a user, though, some people don't like renaming the file on disk in
their target dir, so for these people finalName is useful.
Still it would be best if the gpg plugin at least respected the user
somewhat.
So not a blocking bug, more an annoying one, at least by the sound of it.
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\target\org.apache.uima.textmarker.engine_${parsedVersion
.osgiVersion}.pom.asc to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom.asc
So, we're only seeing this issue due to the fact that we happened to look
into
the /target directory.
-Marshall
On 2/8/2013 12:33 PM, Stephen Connolly wrote:
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've
had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com javascript:;
wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same
as
the
version, except with a period before the SNAPSHOT qualifier, for
example.
This works fine for plugins like the maven-jar-plugin - it nicely
creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because
we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier
steps
(like the maven-jar-plugin) use this and have the correct string (with
the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:;
For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:;
For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;
finalName property
I all, Is there a way to programmatically define the finalName build property? Regards, Romain
gpg plugin signing poms, 2nd finalName part not substituted?
I have a project which specifies in the build a finalName which has 2
substitutable parts:
finalName${project.artifactId}_${parsedVersion.osgiVersion}/finalName
where the parsedVersion.osgiVersion property is set by the
build-helper-maven-plugin, in the first life-cycle-phase.
This property is correctly substituted by the maven-jar-plugin - in that it
builds a jar with the name xyz_2.4.0.jar (assuming for example, that the
project.artifactId is xyz).
This property is correctly substituted by the maven-sources-plugin, too -
building xyz_2.4.0-sources.jar.
However, the maven gpg plugin uses this bit of code to copy the pom to the
target, prior to signing it:
//
// POM
//
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
The file it produces is xyz_${parsedVersion.osgiVersion}.pom.
For some reason, the only the 1st property (${project.artifactId}) is being
substituted, but the 2nd value is not.
The GPG plugin runs after the other plugins - the jar and the sources plugins,
so the property already has a value.
Any ideas on what to do to get the GPG plugin to substitute this value? (I'm
using version 1.3 of the maven-gpg-plugin).
-Marshall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure 'finalName' pattern for all child modules
Wed, 12 Oct 2011 17:42:59 -0700, /Manfred Moser/: 11-10-12 05:30 PM, Yuen-Chi Lian wrote: parent groupIdy/groupId artifactIdx/artifactId versionv/version relativePath../parent/relativePath Dont use relative path ... Why it is not good? I ask because the m2e plugin for Eclipse automatically generates: parent ... relativePath../relativePath /parent for new child modules. As far as I understand the above is the default - is there a difference if it is specified explicitly? -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Configure 'finalName' pattern for all child modules
I want to configure the 'finalName' for a parent module and all its
child modules as:
build
finalName${artifactId}/fileName
/build
Is there a way to configure this as a default pattern in the parent
and avoid repeating it in the 'build' section for all child modules?
--
Stanimir
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure 'finalName' pattern for all child modules
Yes. Have you tried?
$ cat parent/pom.xml | grep finalName
finalName${project.artifactId}-${project.version}-b${buildNumber}/finalName
In the child:
parent
groupIdy/groupId
artifactIdx/artifactId
versionv/version
relativePath../parent/relativePath
Yuen-Chi Lian | www.yclian.com
I do not seek; I find. - Pablo Picasso
2011/10/13 Stanimir Stamenkov s7a...@netscape.net
I want to configure the 'finalName' for a parent module and all its child
modules as:
build
finalName${artifactId}/**fileName
/build
Is there a way to configure this as a default pattern in the parent and
avoid repeating it in the 'build' section for all child modules?
--
Stanimir
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure 'finalName' pattern for all child modules
Dont use relative path ...
11-10-12 05:30 PM, Yuen-Chi Lian wrote:
Yes. Have you tried?
$ cat parent/pom.xml | grep finalName
finalName${project.artifactId}-${project.version}-b${buildNumber}/finalName
In the child:
parent
groupIdy/groupId
artifactIdx/artifactId
versionv/version
relativePath../parent/relativePath
Yuen-Chi Lian | www.yclian.com
I do not seek; I find. - Pablo Picasso
2011/10/13 Stanimir Stamenkovs7a...@netscape.net
I want to configure the 'finalName' for a parent module and all its child
modules as:
build
finalName${artifactId}/**fileName
/build
Is there a way to configure this as a default pattern in the parent and
avoid repeating it in the 'build' section for all child modules?
--
Stanimir
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Configure 'finalName' pattern for all child modules
Thu, 13 Oct 2011 08:30:49 +0800, /Yuen-Chi Lian/:
Yes. Have you tried?
$ cat parent/pom.xml | grep finalName
finalName${project.artifactId}-${project.version}-b${buildNumber}/finalName
Ah, yes - thank you. I've already tried it before but for some
reason I had determined it doesn't work, but seems I've been wrong.
--
Stanimir
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Jar finalName to m2 repository
Hey,
I am trying to get a jar to be uploaded in the maven repository (local as
well as our online repo) under a different name than its default
${project.build.finalName}. I tried changing the finalName under the
build tag as well as under the configuration of the maven-jar-plugin.
These attempts did change the name of the jar in my project/target
directory, however when it's being uploaded it gets its default name again.
...
artifactIdcommon/artifactId
packagingjar/packaging
...
build
finalNameedp/finalName
...
plugin
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
finalNameedp/finalName
/configuration
/plugin
...
output in consule when doing the install/deploy phase:
...
Installing C:\projectsmaven\common\target\edp.jar to
C:\...\.m2\repository\...\common\0.0.1\common-0.0.1.jar
...
When I build wars which depend on this artifact I need the jar to be called
edp-0.0.1.jar in WEB-INF/libs. Now it's still called common-0.0.1.jar
I don't want to use the assembly plugin with descriptor file for this. My
client doesn't know a lot about Maven and they are going to get confused.
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639096.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
Don't fight Maven! Maven uses its convention for naming artifacts in
repositories (i.e. Maven repositories). You cannot change that.
/Anders
On Wed, Aug 18, 2010 at 10:58, fhomasp thomas.peet...@realdolmen.comwrote:
Hey,
I am trying to get a jar to be uploaded in the maven repository (local as
well as our online repo) under a different name than its default
${project.build.finalName}. I tried changing the finalName under the
build tag as well as under the configuration of the maven-jar-plugin.
These attempts did change the name of the jar in my project/target
directory, however when it's being uploaded it gets its default name again.
...
artifactIdcommon/artifactId
packagingjar/packaging
...
build
finalNameedp/finalName
...
plugin
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
finalNameedp/finalName
/configuration
/plugin
...
output in consule when doing the install/deploy phase:
...
Installing C:\projectsmaven\common\target\edp.jar to
C:\...\.m2\repository\...\common\0.0.1\common-0.0.1.jar
...
When I build wars which depend on this artifact I need the jar to be called
edp-0.0.1.jar in WEB-INF/libs. Now it's still called common-0.0.1.jar
I don't want to use the assembly plugin with descriptor file for this. My
client doesn't know a lot about Maven and they are going to get confused.
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639096.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
I can change it if I use the assembly plugin instead of the maven-jar-plugin
:-)
However it would be nice to be able to actually do this using the jar
plugin. I know my client is going to want this library to be called
edp-version.jar.
Anders Hammar wrote:
Don't fight Maven! Maven uses its convention for naming artifacts in
repositories (i.e. Maven repositories). You cannot change that.
/Anders
On Wed, Aug 18, 2010 at 10:58, fhomasp
thomas.peet...@realdolmen.comwrote:
Hey,
I am trying to get a jar to be uploaded in the maven repository (local as
well as our online repo) under a different name than its default
${project.build.finalName}. I tried changing the finalName under the
build tag as well as under the configuration of the maven-jar-plugin.
These attempts did change the name of the jar in my project/target
directory, however when it's being uploaded it gets its default name
again.
...
artifactIdcommon/artifactId
packagingjar/packaging
...
build
finalNameedp/finalName
...
plugin
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
finalNameedp/finalName
/configuration
/plugin
...
output in consule when doing the install/deploy phase:
...
Installing C:\projectsmaven\common\target\edp.jar to
C:\...\.m2\repository\...\common\0.0.1\common-0.0.1.jar
...
When I build wars which depend on this artifact I need the jar to be
called
edp-0.0.1.jar in WEB-INF/libs. Now it's still called common-0.0.1.jar
I don't want to use the assembly plugin with descriptor file for this.
My
client doesn't know a lot about Maven and they are going to get confused.
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639096.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639278.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
Sure, change the artifactId to edp. It's that simple!
/Anders
On Wed, Aug 18, 2010 at 14:28, fhomasp thomas.peet...@realdolmen.comwrote:
I can change it if I use the assembly plugin instead of the
maven-jar-plugin
:-)
However it would be nice to be able to actually do this using the jar
plugin. I know my client is going to want this library to be called
edp-version.jar.
Anders Hammar wrote:
Don't fight Maven! Maven uses its convention for naming artifacts in
repositories (i.e. Maven repositories). You cannot change that.
/Anders
On Wed, Aug 18, 2010 at 10:58, fhomasp
thomas.peet...@realdolmen.comwrote:
Hey,
I am trying to get a jar to be uploaded in the maven repository (local
as
well as our online repo) under a different name than its default
${project.build.finalName}. I tried changing the finalName under the
build tag as well as under the configuration of the maven-jar-plugin.
These attempts did change the name of the jar in my project/target
directory, however when it's being uploaded it gets its default name
again.
...
artifactIdcommon/artifactId
packagingjar/packaging
...
build
finalNameedp/finalName
...
plugin
artifactIdmaven-jar-plugin/artifactId
version2.3.1/version
configuration
finalNameedp/finalName
/configuration
/plugin
...
output in consule when doing the install/deploy phase:
...
Installing C:\projectsmaven\common\target\edp.jar to
C:\...\.m2\repository\...\common\0.0.1\common-0.0.1.jar
...
When I build wars which depend on this artifact I need the jar to be
called
edp-0.0.1.jar in WEB-INF/libs. Now it's still called common-0.0.1.jar
I don't want to use the assembly plugin with descriptor file for this.
My
client doesn't know a lot about Maven and they are going to get
confused.
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639096.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
View this message in context:
http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639278.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
On Wednesday 18 August 2010 fhomasp wrote: I can change it if I use the assembly plugin instead of the maven-jar-plugin You can change the name of the JAR in the local or remote repository with the assembly plugin? I doubt this! You can change the name of the JAR in your targt folder, but that's something completely different and you did this already with the finalName option. Changing the internal data storage of maven (the repository) is a bad idea and therefore not easy to achieve! hth, - martin signature.asc Description: This is a digitally signed message part.
Re: Jar finalName to m2 repository
Well that's out of the question. But ok, at least I'll be able to tell them why it is the way it is ^^ Thanks -- View this message in context: http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639309.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
No, I build the jar using an xml script and call it whatever I want. What and how I insert it into the repository is another thing :-) Martin Höller wrote: On Wednesday 18 August 2010 fhomasp wrote: I can change it if I use the assembly plugin instead of the maven-jar-plugin You can change the name of the JAR in the local or remote repository with the assembly plugin? I doubt this! You can change the name of the JAR in your targt folder, but that's something completely different and you did this already with the finalName option. Changing the internal data storage of maven (the repository) is a bad idea and therefore not easy to achieve! hth, - martin -- View this message in context: http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639323.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Jar finalName to m2 repository
Hi again! On Wednesday 18 August 2010 fhomasp wrote: However it would be nice to be able to actually do this using the jar plugin. I know my client is going to want this library to be called edp-version.jar. Eventually you could find some solution with the maven-dependency-plugins' goal dependency:copy-dependencies in combination with the antrun-plugin. However, it seems you are doing something strange here, which is likely to cause more problems later on. - martin signature.asc Description: This is a digitally signed message part.
Re: Jar finalName to m2 repository
Actually I didn't say i was going to do any of that. It would be a solution, but not nearly good enough. Nah, I'll see if they can live with a different artifactId or with the current name of the jar in the repo and in the lib folder of the wars. Martin Höller wrote: Hi again! On Wednesday 18 August 2010 fhomasp wrote: However it would be nice to be able to actually do this using the jar plugin. I know my client is going to want this library to be called edp-version.jar. Eventually you could find some solution with the maven-dependency-plugins' goal dependency:copy-dependencies in combination with the antrun-plugin. However, it seems you are doing something strange here, which is likely to cause more problems later on. - martin -- View this message in context: http://maven.40175.n5.nabble.com/Jar-finalName-to-m2-repository-tp2639096p2639374.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
property substitution problem in build finalName
In my build I set the build final name for some things using
finalNamea.b.c_${parsedVersion.osgiVersion}/finalName
where ${parsedVersion.osgiVersion} is a parameter value set by executing the
maven-build-helper plugin which is the first plugin run when the build executes
(I checked this and observed it, using the -X debug flag).
If I use the maven-jar-plugin to build the jar, it gets the value of
finalName, which, I suspect, is
a.b.c_${parsedVersion.osgiVersion} and then changes it by substituting the
value of that property, so it comes out something like
a.b.c_2.3.1.
This works fine (it's just what I want) when I use the maven-jar-plugin.
However, I'm now using for some projects the maven-bundle-plugin (groupId
org.apache.felix). This plugin, when it is given the same string, appears to
not rescan it for variables, and does not therefore substitute values. So, its
bundle goal works, but generates the artifact using the name
a.b.c_${parsedVersion.osgiVersion}, which is, obviously, not what I need.
To work around this, I can run an ant-run build step to rename this file. I'm
guessing however, that there could likely be other metadata around that's being
associated to this name, and therefore, this might not be effective.
Maybe I need to do both an ant-run rename, plus a
maven-build-helper:attach-artifact to re-mark the renamed jar as the primary
artifact?
Does anyone have a less kludgy workaround for this kind of issue?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
applying finalName of dependencies when project is packaging
I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S
Re: applying finalName of dependencies when project is packaging
Always a good idea to state *why* you might want to do this so people can provide alternatives. AFAIK the answer is no to your question, but if, for example, you just want to use the artifact name and strip out the version info from the filename, you can use outputFileNameMapping (see http://maven.apache.org/plugins/maven-assembly-plugin/component.html). Kalle On Tue, Jul 20, 2010 at 1:26 PM, Shan Syed shan...@gmail.com wrote: I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: applying finalName of dependencies when project is packaging
Hi, We have a very large set of WAR projects (web services, web applications, static websites, etc) as part of a product offering. Various versions and combinations of these are delivered to clients, but there is no immediate understand of who gets what WARs, what versions, etc. So I am using maven to manage this: I have a POM for each delivery, which just has the dependencies listed, and an assembly descriptor that ZIPs them all conveniently, for deployment/DL to various environments. Each developer has specified a finalName for their WAR, but there is no convention, some require just the version info lopped off, some need a totally different name from their artifact, etc.. there is no reliable way to calculate the desired finalName, for various business reasons. So in my ZIPs for each set of packaged goods, I would like the WARs to have their finalNames, as opposed to their fully qualified maven names. Shan On Tue, Jul 20, 2010 at 4:54 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Always a good idea to state *why* you might want to do this so people can provide alternatives. AFAIK the answer is no to your question, but if, for example, you just want to use the artifact name and strip out the version info from the filename, you can use outputFileNameMapping (see http://maven.apache.org/plugins/maven-assembly-plugin/component.html ). Kalle On Tue, Jul 20, 2010 at 1:26 PM, Shan Syed shan...@gmail.com wrote: I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: applying finalName of dependencies when project is packaging
Just a suggestion, but sounds to me the pom that drives zipping up the artifacts should also be in control of the final names rather than the individual wars. What would happen if two wars specified the same final names? If you cannot dictate a convention for the artifact names I don't see why you'd be able to do it any better for the final names. Kalle On Tue, Jul 20, 2010 at 2:05 PM, Shan Syed shan...@gmail.com wrote: Hi, We have a very large set of WAR projects (web services, web applications, static websites, etc) as part of a product offering. Various versions and combinations of these are delivered to clients, but there is no immediate understand of who gets what WARs, what versions, etc. So I am using maven to manage this: I have a POM for each delivery, which just has the dependencies listed, and an assembly descriptor that ZIPs them all conveniently, for deployment/DL to various environments. Each developer has specified a finalName for their WAR, but there is no convention, some require just the version info lopped off, some need a totally different name from their artifact, etc.. there is no reliable way to calculate the desired finalName, for various business reasons. So in my ZIPs for each set of packaged goods, I would like the WARs to have their finalNames, as opposed to their fully qualified maven names. Shan On Tue, Jul 20, 2010 at 4:54 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Always a good idea to state *why* you might want to do this so people can provide alternatives. AFAIK the answer is no to your question, but if, for example, you just want to use the artifact name and strip out the version info from the filename, you can use outputFileNameMapping (see http://maven.apache.org/plugins/maven-assembly-plugin/component.html ). Kalle On Tue, Jul 20, 2010 at 1:26 PM, Shan Syed shan...@gmail.com wrote: I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: finalName in Ear plugin
Like any other plugin. It refers to the name of the file created when the built project is packaged. In this case, the name of the ear file in the target directory. --- [image: Linkedin] http://www.linkedin.com/in/snicoll[image: Twitter]http://twitter.com/snicoll On Thu, Apr 15, 2010 at 3:13 PM, Timothy Mcginnis tmcgi...@aessuccess.orgwrote: What is the purpose of the finalName tag in the Ear plugin? Tim McGinnis 717 720-1962 Web Development AES/PHEAA == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. ==
finalName in Ear plugin
What is the purpose of the finalName tag in the Ear plugin? Tim McGinnis 717 720-1962 Web Development AES/PHEAA == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. ==
plugin not reading finalName correctly?
Hello, Trying to use buildnumber and tomcat:deploy. In my parent-pom, I've defined buildnumber. In my application-webapp (war), I define the tomcat deploy configuration. However, when tomcat deploy tries to install it, for some reason the buildnumber variable comes across as null. [INFO] Webapp assembled in[120 msecs] [INFO] Building war: /Users/jamesrusso/Documents/workspace/project-maven/project-webapp/target/web-app-0.0.1-SNAPSHOT.3533.war [INFO] [tomcat:deploy] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find war file: /Users/jamesrusso/Documents/workspace/project-maven/project-webapp/target/web-app-0.0.1-SNAPSHOT.null.war I've tried pushing eveything down into the module pom, but same results? Any reason why the tomcat:deploy isn't picking up on the buildnumber variable? thanks, -jr - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: What is the purpose of finalName? really?
Hi Kent, Kent Närling wrote: What IS really the purpose of finalName? It is used to give the resulting artifact a different name locally in your target directory. Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? Definitely. The filename is part of the Maven repository's meta data. Otherwise Maven would have no chance of pulling it from there again. We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? No. These are Maven structures. IIRC there is a possibility to inject a different implementation for the RepositoryManager (or whatever the interface is called), but I am not aware of any alternative implementation. If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? You may either use the local file directly for a hot deployment on your developer machine or you can use additional plugins to process the file further. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is the purpose of finalName? really?
--- Jörg Schaible [EMAIL PROTECTED] schrieb am Fr, 24.10.2008: You may either use the local file directly for a hot deployment on your developer machine or you can use additional plugins to process the file further. To give Kent an example: Consider a pom for building a WAR. If you set finalNamemycontextpath/finalName and use e.g. the jetty plugin to start your webserver in 1 go: $ mvn package jetty:run Then your finalName is being used for 'deployment' and you may access your webapp via http://localhost:8080/mycontextpath/ which may then automatically be regression tested via Canoo, etc without having to type http://localhost:8080/mygroup_id.myartifact_id-2.5.3-SNAPSHOT/ and change the version every time. got it? LieGrü, strub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the purpose of finalName? really?
2008/10/24 Mark Struberg [EMAIL PROTECTED]: To give Kent an example: Consider a pom for building a WAR. If you set finalNamemycontextpath/finalName and use e.g. the jetty plugin to start your webserver in 1 go: $ mvn package jetty:run Then your finalName is being used for 'deployment' and you may access your webapp via http://localhost:8080/mycontextpath/ BTW, the Jetty plugin uses the project's artifact id for its context path :) which may then automatically be regression tested via Canoo, etc without having to type http://localhost:8080/mygroup_id.myartifact_id-2.5.3-SNAPSHOT/ and change the version every time. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the purpose of finalName? really?
Sorry Mark, should have mentioned that I usually use the following config
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-maven-plugin/artifactId
configuration
contextPath${build.finalName}/contextPath
scanIntervalSeconds10/scanIntervalSeconds
/configuration
/plugin
;)
And thanks to bring up the feature with the artifactId.
(I'm not sure if the groupId-artifactId-version behaviour I have in mind is
from either a very old jetty plugin or from the tomcat or cargo plugin i've
worked with. Anyway, it's good to know that this works now.)
LieGrue,
strub
--- Mark Hobson [EMAIL PROTECTED] schrieb am Fr, 24.10.2008:
Von: Mark Hobson [EMAIL PROTECTED]
Betreff: Re: What is the purpose of finalName? really?
An: Maven Users List users@maven.apache.org
Datum: Freitag, 24. Oktober 2008, 9:41
2008/10/24 Mark Struberg [EMAIL PROTECTED]:
To give Kent an example:
Consider a pom for building a WAR.
If you set
finalNamemycontextpath/finalName
and use e.g. the jetty plugin to start your webserver
in 1 go:
$ mvn package jetty:run
Then your finalName is being used for
'deployment' and you may access your webapp via
http://localhost:8080/mycontextpath/
BTW, the Jetty plugin uses the project's artifact id
for its context path :)
which may then automatically be regression tested via
Canoo, etc without having to type
http://localhost:8080/mygroup_id.myartifact_id-2.5.3-SNAPSHOT/
and change the version every time.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the purpose of finalName? really?
2008/10/24 Mark Struberg [EMAIL PROTECTED]:
Sorry Mark, should have mentioned that I usually use the following config
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-maven-plugin/artifactId
configuration
contextPath${build.finalName}/contextPath
scanIntervalSeconds10/scanIntervalSeconds
/configuration
/plugin
;)
And thanks to bring up the feature with the artifactId.
(I'm not sure if the groupId-artifactId-version behaviour I have in mind is
from either a very old jetty plugin or from the tomcat or cargo plugin i've
worked with. Anyway, it's good to know that this works now.)
No worries, that was how the tomcat-maven-plugin worked in
1.0-alpha-1, but I've since changed the trunk to work in the same way
as Jetty (see MOJO-1181). I got tired of guessing the context path :)
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the purpose of finalName? really?
2008/10/24 Jörg Schaible [EMAIL PROTECTED] Hi Kent, Kent Närling wrote: What IS really the purpose of finalName? It is used to give the resulting artifact a different name locally in your target directory. only locally? a bit limited usefulness, but ok if that is the defined purpose... Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? Definitely. The filename is part of the Maven repository's meta data. Otherwise Maven would have no chance of pulling it from there again. Well, technically speaking... it COULD have looked in the POM file to find out which filename to look for... ;-) We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? No. These are Maven structures. IIRC there is a possibility to inject a different implementation for the RepositoryManager (or whatever the interface is called), but I am not aware of any alternative implementation. Ok, but I was kind of hoping that we could use the maven repository as a product download repository as well, which would have been nice? (anyone else see the logic in this?) Essentially what we are looking for is to make the release process automated and standarddized with maven, including making it available to our delivery department. ie. when doing a release: - branching/taging it etc (done nicely by the relase plugin already) - uploading it to the repository for dependencies etc (done by maven nicely already) - updating a project site with product information , release notes and download links to the artifacts belonging to it (so they can grab it and install it at a customer) - sending a release mail to relevant parties with links to the updated product site, possibly with release notes etc What would be the recommended maven way to achieve this behaviour? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? You may either use the local file directly for a hot deployment on your developer machine or you can use additional plugins to process the file further. Well, that is hardly a practical solution for non-developers ... ;-)
Re: What is the purpose of finalName? really?
You may either use the local file directly for a hot deployment on your developer machine or you can use additional plugins to process the file further. To give Kent an example: Consider a pom for building a WAR. If you set finalNamemycontextpath/finalName and use e.g. the jetty plugin to start your webserver in 1 go: $ mvn package jetty:run Then your finalName is being used for 'deployment' and you may access your webapp via http://localhost:8080/mycontextpath/ Well, this is all very nice... but not so practical for creating a proper context for a production environment? Also, to make things more annoying, tomcat has a tendency to ignore symlink names and picking the actual filename (pointed to by the symlink) as context ANYWAY!?! It is possible to work around this, but it seems it gets quite messy... so our best solution so far is to make sure that the actual filename matches the desired context name...
Re: What is the purpose of finalName? really?
On Fri, Oct 24, 2008 at 1:56 PM, Kent Närling [EMAIL PROTECTED] wrote: Ok, but I was kind of hoping that we could use the maven repository as a product download repository as well, which would have been nice? (anyone else see the logic in this?) ... - updating a project site with product information , release notes and download links to the artifacts belonging to it (so they can grab it and install it at a customer) For this, I would create an assembly (zip or .tar.gz distribution) with the artifacts and documentation. The assembly is still going to have the version number in the filename when it gets deployed to the repository, but I bet you can find a way to remove the version number in the files *inside* the assembly. Another idea to get a version-less filename without duplicating the file: use a symlink on the repository server. So you might have repo.mycompany.com/maven2/com/mycompany/project/1.0/project-1.0.war and repo.mycompany.com/dist/project.war which is just a link to the original. The link would have to be updated for each release. Or you could get even fancier with some code that served up the latest version based on the repository metadata when it got a request for 'project.war'. (Actually this thread already prompted a feature request for a repository manager to allow browsing to groupId/artifactId/[latest|release] based on the metadata.) HTH, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is the purpose of finalName? really?
What IS really the purpose of finalName? Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? Best regards Kent
Re: What is the purpose of finalName? really?
For us we use it to ensure that the war file in target is always the same, so that other scripts we have can pick it up irrespective of the version. If you are pulling the file out of the repo, you can always specify the name to pull it out of the repo as 2008/10/23 Kent Närling [EMAIL PROTECTED] What IS really the purpose of finalName? Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? Best regards Kent
Re: What is the purpose of finalName? really?
Exactly what we wanted too! But when I do this, the filename in the repository gets the default name anyway!! When running it locally for instance, I get the following message: [INFO] Installing C:\Workspaces\main\requestparser\requestparser-servlet\target\requestparser-servletxx.war to C:\Documents and Settings\kent\.m2\repository\com\seamless\ers\requestparser-servlet\1.0rc3-SNAPSHOT\requestparser-servlet-1.0rc3-SNAPSHOT.war ie, it seems the install plugin simply ignores the finalName tag?!? I mean, obviously it is nice to have a war file have a fixed name since it usually dictates the default path to the context in the container and you don't want the version in that?!? Naturally it is possible to manually re-name it, but that kind of defeats the purpose of a company repository if you have to re-name the files before you use them?!? 2008/10/23 Stephen Connolly [EMAIL PROTECTED] For us we use it to ensure that the war file in target is always the same, so that other scripts we have can pick it up irrespective of the version. If you are pulling the file out of the repo, you can always specify the name to pull it out of the repo as 2008/10/23 Kent Närling [EMAIL PROTECTED] What IS really the purpose of finalName? Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? Best regards Kent -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: [EMAIL PROTECTED] www.seamless.se
Re: What is the purpose of finalName? really?
But why are you pulling them from your repo by hand. When we need to get the artifact we copy it out of the local repo with either the dependencies:copy goal in a little project, or with maven ant tasks Both of these allow us to control the name. 2008/10/23 Kent Närling [EMAIL PROTECTED] Exactly what we wanted too! But when I do this, the filename in the repository gets the default name anyway!! When running it locally for instance, I get the following message: [INFO] Installing C:\Workspaces\main\requestparser\requestparser-servlet\target\requestparser-servletxx.war to C:\Documents and Settings\kent\.m2\repository\com\seamless\ers\requestparser-servlet\1.0rc3-SNAPSHOT\requestparser-servlet-1.0rc3-SNAPSHOT.war ie, it seems the install plugin simply ignores the finalName tag?!? I mean, obviously it is nice to have a war file have a fixed name since it usually dictates the default path to the context in the container and you don't want the version in that?!? Naturally it is possible to manually re-name it, but that kind of defeats the purpose of a company repository if you have to re-name the files before you use them?!? 2008/10/23 Stephen Connolly [EMAIL PROTECTED] For us we use it to ensure that the war file in target is always the same, so that other scripts we have can pick it up irrespective of the version. If you are pulling the file out of the repo, you can always specify the name to pull it out of the repo as 2008/10/23 Kent Närling [EMAIL PROTECTED] What IS really the purpose of finalName? Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? Best regards Kent -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: [EMAIL PROTECTED] www.seamless.se
Re: What is the purpose of finalName? really?
Well, when our deployment team wants to install eg a new version of a component, they just download it from the repo. And they don't run maven, for them the repo is just a download server, which is kind of natural, or? Why keep another copy of all artifact versions etc? Is this a very unusual way of using a maven repo? On 23/10/2008, Stephen Connolly [EMAIL PROTECTED] wrote: But why are you pulling them from your repo by hand. When we need to get the artifact we copy it out of the local repo with either the dependencies:copy goal in a little project, or with maven ant tasks Both of these allow us to control the name. 2008/10/23 Kent Närling [EMAIL PROTECTED] Exactly what we wanted too! But when I do this, the filename in the repository gets the default name anyway!! When running it locally for instance, I get the following message: [INFO] Installing C:\Workspaces\main\requestparser\requestparser-servlet\target\requestparser-servletxx.war to C:\Documents and Settings\kent\.m2\repository\com\seamless\ers\requestparser-servlet\1.0rc3-SNAPSHOT\requestparser-servlet-1.0rc3-SNAPSHOT.war ie, it seems the install plugin simply ignores the finalName tag?!? I mean, obviously it is nice to have a war file have a fixed name since it usually dictates the default path to the context in the container and you don't want the version in that?!? Naturally it is possible to manually re-name it, but that kind of defeats the purpose of a company repository if you have to re-name the files before you use them?!? 2008/10/23 Stephen Connolly [EMAIL PROTECTED] For us we use it to ensure that the war file in target is always the same, so that other scripts we have can pick it up irrespective of the version. If you are pulling the file out of the repo, you can always specify the name to pull it out of the repo as 2008/10/23 Kent Närling [EMAIL PROTECTED] What IS really the purpose of finalName? Apparently, the install plugin ignores the artifact name when deploying it to the repository anyway?? We would like to have a version-less filename on the artifact in the repository (the version is in the path anyway), is this possible? If not, what is the real purpose of finalName if it is not used for the name of the artifact/file in the end anyway... ? Best regards Kent -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: [EMAIL PROTECTED] www.seamless.se -- Kent Närling System Architect SEAMLESS Dalagatan 100, 8 tr, 113 43 Stockholm, Sweden Phone: +46 8 5648 7800, fax: +46 8 5648 7823 Mobile: +46 70 836 9925 Mail: [EMAIL PROTECTED] www.seamless.se - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
Traditionally, Maven regards the repository as a database for artifacts. This means that anything in the repository is meant to be reachable by Maven. Having said that, most repositories live on some sort of webserver somewhere, which means the Maven repository is usually just a directory structure on that webserver...which leads me to my real point: The intention with all of this was that Maven would index/name artifacts the way it needed to in order to retrieve them when they're in the repository. The finalName configurations are preserved in the POM, which is deployed alongside the artifact. So, anyone who requires an artifact to comply with its configured finalName should have the appropriate plugins in place during their build (or whatever) to copy the artifact out of the repository system into a different directory with the finalName-compliant file name. Now, if you have no intention of accessing these custom-named files from Maven, why deploy them to a Maven repository? Why not deploy them *alongside* the Maven repository on the same webserver? This wouldn't be done using the typical deployment mechanism, but rather a custom plugin that would just push the file (I'm assuming you don't need the POM, either) to the appropriate location, either locally or remotely. In other words, try not to bend the Maven repository to your external needs. If you can't work with its format, perhaps you'd be better off constructing your own directory/file structure alongside the repository? HTH, john On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote: I'm not insisting on it either. The artifacts were deployed automatically when we deploy the parent project. As far as I know we don't need them in the repository though. I'll have to take a closer look. Thanks for your help. On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Michael Dick
Question regarding finalName in maven-assembly-plugin
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
There is no way for maven to access an artifact in the repository if
it does not follow the standard naming conventions.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
Thank you for the explanation,
Wouldn't it be possible to store the finalName in the
maven-metadata.xmlfile or another xml file in the repository? We
already have a unique path in
the repository ${groupId}/${artifactId}/${version}. I'm not interested in
changing the path, just the name of the final jar / zip / whatever.
It seems that the finalName *could* be added in an xml file in the
repository. Whether it *should* be added is another issue.
FTR I'm just curious whether this is a possibility, or if anyone else thinks
it would be a good idea. I did look through the mailing list archives
unfortunately after I posted the question) and I know this issue has come up
before.
Thanks again,
Michael Dick
On 4/11/07, Heinrich Nirschl [EMAIL PROTECTED] wrote:
On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi,
I've noticed that the finalName configuration option for an assembly is
ignored when you install or deploy your project. Is this intended
behavior?
I have a project named openjpa-project which contains the a source and
binary assembly which packages various OpenJPA sub-projects. We'd like
to
have the resulting zip files named openjpa-${version}-source.zip and
openjpa-${version}-binary.zip, but we're getting
openjpa-project-${version}-
source.zip (and the same for -binary) when we deploy or install.
I can provide pom and assembly files if that would help.
Thanks,
--
-Michael Dick
There is no way for maven to access an artifact in the repository if
it does not follow the standard naming conventions.
Henry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. FTR I'm just curious whether this is a possibility, or if anyone else thinks it would be a good idea. I did look through the mailing list archives unfortunately after I posted the question) and I know this issue has come up before. Thanks again, Michael Dick On 4/11/07, Heinrich Nirschl [EMAIL PROTECTED] wrote: On 4/11/07, Michael Dick [EMAIL PROTECTED] wrote: Hi, I've noticed that the finalName configuration option for an assembly is ignored when you install or deploy your project. Is this intended behavior? *snip* -- -Michael Dick There is no way for maven to access an artifact in the repository if it does not follow the standard naming conventions. Henry I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 01:27:42PM -0500, Michael Dick spake thus: *snip* It seems that the finalName *could* be added in an xml file in the repository. Whether it *should* be added is another issue. I did not think too much about that, but I guess that something like this *could* be implemented. There would still be some issues with snapshot deployments. Also, one has to be careful not to slow down the standard case by an extra file access. I have projects that create artifacts with a 'finalName' set, and these artifacts get installed/deployed with the wrong file names (that is, not what I specified in 'finalName'). In all of my cases, these artifacts do not need to be accessible by maven for build purposes, so the fact that the files are installed and deployed with names different from what I specified in 'finalName' is simply an annoyance (because I then have to rename the files on the deployment server by hand). Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding finalName in maven-assembly-plugin
I'm not insisting on it either. The artifacts were deployed automatically when we deploy the parent project. As far as I know we don't need them in the repository though. I'll have to take a closer look. Thanks for your help. On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 09:45:17PM +0200, Heinrich Nirschl spake thus: *snip* On 4/11/07, Alan D. Salewski [EMAIL PROTECTED] wrote: Maybe we need an attribute for 'finalName' that indicates yes I know this name will not be accessible by maven once installed or deployed; when set maven would deploy the file as named. Why insist to put something into a *maven* repository if there is no intention to access it by maven? Wouldn't it be more useful to be able to publish to a different place? I don't know, if there already is a plugin achieving that, but it would not be too hard to build. Henry I'm not insisting on it; in fact, I like your idea much better ;-) Our current practice of deploying all of our artifacts to our internal maven repository came about because the infrastructure was already in place and accessible by everyone who needed access to the artifacts. Now that you mention it, though, it would make sense to have an arbitrary deployment plugin. There is precedence for this with other specialized deployment plugins (cargo, tomcat, probably others). -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Michael Dick
maven-ejb-plugin and finalName in build (ignored?)
Hi,
I pasted below part of my pom file. I'd like the EJB jar file to be called
myEjbJar.jar.
Instead the file is named {artifactId}-{version}.jar.
Is there a way to make it work? I thought finalName inside build should
override the default jar file name.
Any help on the subject would be greatly appreciated.
Thanks,
Bratek
build
finalNamemyEjbJar/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
generateClienttrue/generateClient
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
/configuration
/plugin
/plugins
/build
--
View this message in context:
http://www.nabble.com/maven-ejb-plugin-and-finalName-in-build-%28ignored-%29-tf3279514s177.html#a9120997
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: finalName
On 10/30/06, Wendy Smoak [EMAIL PROTECTED] wrote:
Okay, so the docs for finalName differ on
http://maven.apache.org/maven-v4_0_0.xsd
and
http://maven.apache.org/ref/2.0.4/maven-model/maven.html
My guess is that the xsd needs to be re-generated, since the 2.0.4
docs describe the current behavior.
Shelley, thanks for bringing this up. The xsd has been re-generated
and published. The docs for finalName now read:
The filename (excluding the extension, and with no path information)
that the produced
artifact will be called. The default value is ${artifactId}-${version}
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
finalName
The 4.0.0 POM schema indicates that the finalName includes the extension [1], but when running package, the default packaging type extension is automatically appended. For example, if finalNametest.zip/finalName is used for a jar project, the resulting artifact is test.zip.jar. Is this an issue with the package goal or a miscommunication in the xsd? [1] http://maven.apache.org/maven-v4_0_0.xsd - Get your email and see which of your friends are online - Right on the new Yahoo.com
Re: finalName
On 10/30/06, Shelley Lock [EMAIL PROTECTED] wrote:
The 4.0.0 POM schema indicates that the finalName includes the extension [1], but when running
package, the default packaging type extension is automatically appended. For example, if
finalNametest.zip/finalName is used for a jar project, the resulting artifact is
test.zip.jar. Is this an issue with the package goal or a miscommunication in the xsd?
Shelley, the xsd for Maven 2.0.4 differs from the comments that you
pasted on MNG-1676. What version did you copy that from?
From http://maven.apache.org/ref/2.0.4/maven-model/maven.html :
finalNameThe filename (excluding the extension, and with no path
information) that the produced artifact will be called. The default
value is ${artifactId}-${version}.
(This started as discussion on http://jira.codehaus.org/browse/MNG-1676 .)
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: finalName
On 10/30/06, Wendy Smoak [EMAIL PROTECTED] wrote: Shelley, the xsd for Maven 2.0.4 differs from the comments that you pasted on MNG-1676. What version did you copy that from? Must read footnotes. :) Okay, so the docs for finalName differ on http://maven.apache.org/maven-v4_0_0.xsd and http://maven.apache.org/ref/2.0.4/maven-model/maven.html My guess is that the xsd needs to be re-generated, since the 2.0.4 docs describe the current behavior. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not working
Doug,
thanks for your reply.
Yes that's true, Maven has no knowledge of projet A. But it knows that A
is a dependency. So it should include A as a reference in module B using
the finalName: is it completly non sens?
Moreover I found dangerous that the behavior is not the same when
building projet B alone or when building within a multimodule.
finalName is not used for the repository which is perfect. But the
finalName doesn't only effect the name of the artifact but also
references in ClassPath entry of the manifest file, references in
application.xml for EAR or references in WEB-INF/lib for web module...
Yann
Doug Douglass wrote:
Yann,
This is to be expected. When running maven in your B project, maven has no
knowledge of project A as a module to be built and referenced, only as a
dependency that needs to be retrieved from a repository and added to the
classpath.
In addition, finalName only effects the name of the artifact generated in
the target directory. If you install/deploy the same artifact it will
(should) have the standard naming of ${artifactId}-${version}. This is A
Good Thing, as it prevents ambiguity in the repository.
HTH,
Doug
On 10/12/06, Yann Albou [EMAIL PROTECTED] wrote:
Hi,
I try to use the finalName in my parent pom as following:
finalName${artifactId}/finalName (without the version number)
If I run maven from the parent pom everything works fine: all my
artifacts are generated without the version number. and also the
classpath entry of the manifest.mf file is correctly set.
For instance I get :
parent
--- A module
--- B module (with a dependency on A)
So it generates B.jar with a Manifest containning ClassPath: A.Jar
Now If I run maven from B module it generates a B.jar but with a
manifest containing ClassPath: A-1.2.1.Jar for instance.
I get exactly the same behaviour with an EAR module that generate the
application.xml = module are not generated with the correct name...
If I run maven from the parent pom then the application.xml is generated
correctly
Did I miss something ?
Yann.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not working
In the last couple of months, this same discussion has come up once or
twice. I believe someone even suggested adding another node to
dependency to allow you to change the name of the artifact when it
was brought into your project/jar/war. There might even be a JIRA
already posted as an enchancement request, something along these
lines:
dep
groupId/
artifactId/
version/
scope/
finalNameblah.jar/finalName
/dep
Ultimately, arguing over how this should work in Maven 2.0 is an
exercise in futility. Your time will be better spent convincing the
Maven Dev team to somehow make it work and add it to M2.1. You will
need a fairly strong business case to make this happen I would think,
as it seems to go against many of the Maven best practices in my mind.
Additionally... you **could** make this work today in M2.0 by using
System scope and specifying the path to the dependency as
../projectA/target/finalName.jar. But I am generally anti-system-scope
(due to various unintended consequences w/it), so please don't
complain if this screws some other things up...
Wayne
On 10/15/06, Yann Albou [EMAIL PROTECTED] wrote:
Doug,
thanks for your reply.
Yes that's true, Maven has no knowledge of projet A. But it knows that A
is a dependency. So it should include A as a reference in module B using
the finalName: is it completly non sens?
Moreover I found dangerous that the behavior is not the same when
building projet B alone or when building within a multimodule.
finalName is not used for the repository which is perfect. But the
finalName doesn't only effect the name of the artifact but also
references in ClassPath entry of the manifest file, references in
application.xml for EAR or references in WEB-INF/lib for web module...
Yann
Doug Douglass wrote:
Yann,
This is to be expected. When running maven in your B project, maven has no
knowledge of project A as a module to be built and referenced, only as a
dependency that needs to be retrieved from a repository and added to the
classpath.
In addition, finalName only effects the name of the artifact generated in
the target directory. If you install/deploy the same artifact it will
(should) have the standard naming of ${artifactId}-${version}. This is A
Good Thing, as it prevents ambiguity in the repository.
HTH,
Doug
On 10/12/06, Yann Albou [EMAIL PROTECTED] wrote:
Hi,
I try to use the finalName in my parent pom as following:
finalName${artifactId}/finalName (without the version number)
If I run maven from the parent pom everything works fine: all my
artifacts are generated without the version number. and also the
classpath entry of the manifest.mf file is correctly set.
For instance I get :
parent
--- A module
--- B module (with a dependency on A)
So it generates B.jar with a Manifest containning ClassPath: A.Jar
Now If I run maven from B module it generates a B.jar but with a
manifest containing ClassPath: A-1.2.1.Jar for instance.
I get exactly the same behaviour with an EAR module that generate the
application.xml = module are not generated with the correct name...
If I run maven from the parent pom then the application.xml is generated
correctly
Did I miss something ?
Yann.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not working
Yann,
This is to be expected. When running maven in your B project, maven has no
knowledge of project A as a module to be built and referenced, only as a
dependency that needs to be retrieved from a repository and added to the
classpath.
In addition, finalName only effects the name of the artifact generated in
the target directory. If you install/deploy the same artifact it will
(should) have the standard naming of ${artifactId}-${version}. This is A
Good Thing, as it prevents ambiguity in the repository.
HTH,
Doug
On 10/12/06, Yann Albou [EMAIL PROTECTED] wrote:
Hi,
I try to use the finalName in my parent pom as following:
finalName${artifactId}/finalName (without the version number)
If I run maven from the parent pom everything works fine: all my
artifacts are generated without the version number. and also the
classpath entry of the manifest.mf file is correctly set.
For instance I get :
parent
--- A module
--- B module (with a dependency on A)
So it generates B.jar with a Manifest containning ClassPath: A.Jar
Now If I run maven from B module it generates a B.jar but with a
manifest containing ClassPath: A-1.2.1.Jar for instance.
I get exactly the same behaviour with an EAR module that generate the
application.xml = module are not generated with the correct name...
If I run maven from the parent pom then the application.xml is generated
correctly
Did I miss something ?
Yann.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] finalName not working
Hi,
I try to use the finalName in my parent pom as following:
finalName${artifactId}/finalName (without the version number)
If I run maven from the parent pom everything works fine: all my
artifacts are generated without the version number. and also the
classpath entry of the manifest.mf file is correctly set.
For instance I get :
parent
--- A module
--- B module (with a dependency on A)
So it generates B.jar with a Manifest containning ClassPath: A.Jar
Now If I run maven from B module it generates a B.jar but with a
manifest containing ClassPath: A-1.2.1.Jar for instance.
I get exactly the same behaviour with an EAR module that generate the
application.xml = module are not generated with the correct name...
If I run maven from the parent pom then the application.xml is generated
correctly
Did I miss something ?
Yann.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] does mvn install ignore finalName?
I configured the finalname in the pom to something like this: finelNameabcfinalName After mvn install there is a file with the name abc.jar in the target folder, as expected. But in the maven repository the filename still has the form artifactid-version.jar, the finalName seems to be ignored. Is there a way to have a custom filename like abc.jar in the repository, or would this violate basic maven2 concepts? Tom __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] does mvn install ignore finalName?
Such files (abc.jar) should be uploaded using assembly plugin, which can attach another artifact to the instlal phase. I guess the standard jar is always deployed, to be available for dependency... Denis. Tom Will wrote: I configured the finalname in the pom to something like this: finelNameabcfinalName After mvn install there is a file with the name abc.jar in the target folder, as expected. But in the maven repository the filename still has the form artifactid-version.jar, the finalName seems to be ignored. Is there a way to have a custom filename like abc.jar in the repository, or would this violate basic maven2 concepts? Tom __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--does-mvn-install-ignore-finalName--tf2157431.html#a5960211 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2]assembly plugin: finalName issue
Hello, I've set, in the configuration of the assembly plugin, the finalName property. Unfortunately, the plugin keeps appending in the file name -src between the finalName value and the extension (.zip, .tar.gz) specified in the assembly config file. Does anybody know if it's possible to get rid of this -src thing? Thanks, Sebastien -- Sebastien Pennec [EMAIL PROTECTED] LOGBack: the generic, reliable, fast and flexible logging library for Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2]assembly plugin: finalName issue
hi, if src is the id specified in your assembly XML file, try add appendAssemblyIdfalse/appendAssemblyId in your assembly configuration's section in your pom.xml. Stéphane. Sebastien Pennec a écrit : Hello, I've set, in the configuration of the assembly plugin, the finalName property. Unfortunately, the plugin keeps appending in the file name -src between the finalName value and the extension (.zip, .tar.gz) specified in the assembly config file. Does anybody know if it's possible to get rid of this -src thing? Thanks, Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2]assembly plugin: finalName issue
if worked perfectly, thanks! :) Sebastien Stéphane Bouchet a écrit : hi, if src is the id specified in your assembly XML file, try add appendAssemblyIdfalse/appendAssemblyId in your assembly configuration's section in your pom.xml. Stéphane. Sebastien Pennec a écrit : Hello, I've set, in the configuration of the assembly plugin, the finalName property. Unfortunately, the plugin keeps appending in the file name -src between the finalName value and the extension (.zip, .tar.gz) specified in the assembly config file. Does anybody know if it's possible to get rid of this -src thing? Thanks, Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sebastien Pennec [EMAIL PROTECTED] LOGBack: the generic, reliable, fast and flexible logging library for Java. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName ${version} being picked up from System properties?
I guess this was missed when I sent a couple weeks ago, does anyone have
any thoughts on this? Should I file a JIRA issue?
Thanks,
Chad
Chad Brandon wrote:
Hi,
I'm using maven 2.0.1 for AndroMDA's build (its a fairly large
multiproject build).
It appears that if I have a version property in my System
properties, it sometimes gets picked up and used for the version of my
project when creating the final name (during pom interpolation I'm
assuming). I then get an unresolved dependency error because of
course the version is not the one defined as the version in my
pom.xml. Is this a know issue and shouldn't information in the pom
take precedence over System properties? I'm assuming this call in
DefaultMavenProjectBuilder is the culprit (since this context is then
passed to the RegexBasedModelInterpolator for use in project
interpolation) :
// TODO: Clean this up...we're using this to 'jump' the
interpolation step for model properties not expressed in XML.
// [BP] - Can this above comment be explained?
// We don't need all the project methods that are added over
those in the model, but we do need basedir
Map context = new HashMap( System.getProperties() );
I also have a similar issue with ${basedir}, the value that sometimes
gets picked up, is the value for the previous project (which of course
breaks the build), I resorted to using ${pom.basedir} which seems to
fix things. I've tried using ${pom.version} instead of ${version}
to fix my issue with the wrong version, however it doesn't help
because it looks like the DefaultModelInheritanceAssembler sets the
final name as ${artifactId}-${version} (I put some debug in that
code to see what was being set). For now I've put a hack in one of my
m2 plugins to remove the version System property (not sure where its
coming from really) so that I can get past this, but of course this
isn't the best solution :)
Thanks,
Chad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] finalName ${version} being picked up from System properties?
Hi,
I'm using maven 2.0.1 for AndroMDA's build (its a fairly large
multiproject build).
It appears that if I have a version property in my System properties,
it sometimes gets picked up and used for the version of my project when
creating the final name (during pom interpolation I'm assuming). I
then get an unresolved dependency error because of course the version is
not the one defined as the version in my pom.xml. Is this a know issue
and shouldn't information in the pom take precedence over System
properties? I'm assuming this call in DefaultMavenProjectBuilder is the
culprit (since this context is then passed to the
RegexBasedModelInterpolator for use in project interpolation) :
// TODO: Clean this up...we're using this to 'jump' the
interpolation step for model properties not expressed in XML.
// [BP] - Can this above comment be explained?
// We don't need all the project methods that are added over
those in the model, but we do need basedir
Map context = new HashMap( System.getProperties() );
I also have a similar issue with ${basedir}, the value that sometimes
gets picked up, is the value for the previous project (which of course
breaks the build), I resorted to using ${pom.basedir} which seems to fix
things. I've tried using ${pom.version} instead of ${version} to
fix my issue with the wrong version, however it doesn't help because it
looks like the DefaultModelInheritanceAssembler sets the final name as
${artifactId}-${version} (I put some debug in that code to see what
was being set). For now I've put a hack in one of my m2 plugins to
remove the version System property (not sure where its coming from
really) so that I can get past this, but of course this isn't the best
solution :)
Thanks,
Chad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not taken into account in install
Yep, that's the idea. One of two things ends up occuring: 1) you have to copy it from the local repository to a staging directory to prepare it, in which case you rename it on the way 2) you include it sourced directly from the local repo, but specify a filename it will use in the target, where you rename it You might also be interested in the recent enhancements to the assembly plugin and discussions on JIRA for creating NSIS installers - the same interface should be used for your installshield plugin I imagine. Cheers, Brett On 11/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: ok, I understand. The better way is probably to rename them in the project that needs them unversioned (my InstallShield merge module) when downloading the dependencies. 2005/11/25, Brett Porter [EMAIL PROTECTED]: Sorry, I've closed this as won't fix. http://maven.apache.org/maven-1.x/faq.html#unversioned-jars On 11/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: Done: http://jira.codehaus.org/browse/MNG-1676 Wim 2005/11/24, Jason van Zyl [EMAIL PROTECTED]: Wim Deblauwe wrote: Hi, when I set finalName/ in my pom.xml, the install plugin does not take this name into account. Just for testing I added finalNametest.jar/finalName to the pom.xmlof a custom plugin of mine. When doing 'mvn install', I get this: [INFO] Installing Y:\wimd_test_vob\modules\maven-plugins\maven-nmake-plugin\target\test.jar.jar to C:\Documents and Settings\WIMD\.m2\repository\com\barcoview\mavenplugin\maven-nmake-plugin\1.0-SNAPSHOT\maven- nmake-plugin-1.0-SNAPSHOT.jar I was hoping it would install to the directory it does, but as test.jar. Can you raise an issue in JIRA? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] finalName not taken into account in install
Hi, when I set finalName/ in my pom.xml, the install plugin does not take this name into account. Just for testing I added finalNametest.jar/finalName to the pom.xml of a custom plugin of mine. When doing 'mvn install', I get this: [INFO] Installing Y:\wimd_test_vob\modules\maven-plugins\maven-nmake-plugin\target\test.jar.jar to C:\Documents and Settings\WIMD\.m2\repository\com\barcoview\mavenplugin\maven-nmake-plugin\1.0-SNAPSHOT\maven- nmake-plugin-1.0-SNAPSHOT.jar I was hoping it would install to the directory it does, but as test.jar. regards, Wim
Re: [m2] finalName not taken into account in install
Wim Deblauwe wrote: Hi, when I set finalName/ in my pom.xml, the install plugin does not take this name into account. Just for testing I added finalNametest.jar/finalName to the pom.xml of a custom plugin of mine. When doing 'mvn install', I get this: [INFO] Installing Y:\wimd_test_vob\modules\maven-plugins\maven-nmake-plugin\target\test.jar.jar to C:\Documents and Settings\WIMD\.m2\repository\com\barcoview\mavenplugin\maven-nmake-plugin\1.0-SNAPSHOT\maven- nmake-plugin-1.0-SNAPSHOT.jar I was hoping it would install to the directory it does, but as test.jar. Can you raise an issue in JIRA? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not taken into account in install
Done: http://jira.codehaus.org/browse/MNG-1676 Wim 2005/11/24, Jason van Zyl [EMAIL PROTECTED]: Wim Deblauwe wrote: Hi, when I set finalName/ in my pom.xml, the install plugin does not take this name into account. Just for testing I added finalNametest.jar/finalName to the pom.xmlof a custom plugin of mine. When doing 'mvn install', I get this: [INFO] Installing Y:\wimd_test_vob\modules\maven-plugins\maven-nmake-plugin\target\test.jar.jar to C:\Documents and Settings\WIMD\.m2\repository\com\barcoview\mavenplugin\maven-nmake-plugin\1.0-SNAPSHOT\maven- nmake-plugin-1.0-SNAPSHOT.jar I was hoping it would install to the directory it does, but as test.jar. Can you raise an issue in JIRA? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] finalName not taken into account in install
ok, I understand. The better way is probably to rename them in the project that needs them unversioned (my InstallShield merge module) when downloading the dependencies. 2005/11/25, Brett Porter [EMAIL PROTECTED]: Sorry, I've closed this as won't fix. http://maven.apache.org/maven-1.x/faq.html#unversioned-jars On 11/25/05, Wim Deblauwe [EMAIL PROTECTED] wrote: Done: http://jira.codehaus.org/browse/MNG-1676 Wim 2005/11/24, Jason van Zyl [EMAIL PROTECTED]: Wim Deblauwe wrote: Hi, when I set finalName/ in my pom.xml, the install plugin does not take this name into account. Just for testing I added finalNametest.jar/finalName to the pom.xmlof a custom plugin of mine. When doing 'mvn install', I get this: [INFO] Installing Y:\wimd_test_vob\modules\maven-plugins\maven-nmake-plugin\target\test.jar.jar to C:\Documents and Settings\WIMD\.m2\repository\com\barcoview\mavenplugin\maven-nmake-plugin\1.0-SNAPSHOT\maven- nmake-plugin-1.0-SNAPSHOT.jar I was hoping it would install to the directory it does, but as test.jar. Can you raise an issue in JIRA? -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build artifact finalName - when to use ?
Apologies I meant to write 'in a EJB's pom.xml' i.e when building an ejb jar On 09/11/05, Stephane Nicoll [EMAIL PROTECTED] wrote: I don't get the in an EAR's pom. Do you mean with an EAR packaging? Stéphane. On 11/9/05, Pete [EMAIL PROTECTED] wrote: Is it a good idea to use build finalNamemyEjb.jar/finalName in an EAR's pom.xml so that when this ejb jar is included in an EAR, it already has the simple name (without the SNAPSHOT... suffix), without resorting to bundleFileName entries in the EAR's pom.xml I believe this will still install the ejb jar with SNAPSHOT... suffix in the repository So is this the best practice ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build artifact finalName - when to use ?
I'll rewrite :- Is it a good idea to use build finalNamemyEjb.jar/finalName in an EJB's pom.xml (when building an ejb jar) so that when this ejb jar is included in an EAR artifact, it already has the simple name (without the SNAPSHOT... suffix), without resorting to bundleFileName entries in the EAR's pom.xml I believe this will still install the ejb jar with SNAPSHOT... suffix in the repository So is this the best practice ? On 10/11/05, Pete [EMAIL PROTECTED] wrote: Apologies I meant to write 'in a EJB's pom.xml' i.e when building an ejb jar On 09/11/05, Stephane Nicoll [EMAIL PROTECTED] wrote: I don't get the in an EAR's pom. Do you mean with an EAR packaging? Stéphane. On 11/9/05, Pete [EMAIL PROTECTED] wrote: Is it a good idea to use build finalNamemyEjb.jar/finalName in an EAR's pom.xml so that when this ejb jar is included in an EAR, it already has the simple name (without the SNAPSHOT... suffix), without resorting to bundleFileName entries in the EAR's pom.xml I believe this will still install the ejb jar with SNAPSHOT... suffix in the repository So is this the best practice ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build artifact finalName - when to use ?
Is it a good idea to use build finalNamemyEjb.jar/finalName in an EAR's pom.xml so that when this ejb jar is included in an EAR, it already has the simple name (without the SNAPSHOT... suffix), without resorting to bundleFileName entries in the EAR's pom.xml I believe this will still install the ejb jar with SNAPSHOT... suffix in the repository So is this the best practice ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build artifact finalName - when to use ?
I don't get the in an EAR's pom. Do you mean with an EAR packaging? Stéphane. On 11/9/05, Pete [EMAIL PROTECTED] wrote: Is it a good idea to use build finalNamemyEjb.jar/finalName in an EAR's pom.xml so that when this ejb jar is included in an EAR, it already has the simple name (without the SNAPSHOT... suffix), without resorting to bundleFileName entries in the EAR's pom.xml I believe this will still install the ejb jar with SNAPSHOT... suffix in the repository So is this the best practice ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::.
[m2] finalName in install and version for different environments
I have a project to build / deploy for three different enviroments (test,integration, production with different configs) and want to set the jar file name depending on the active profile. I know one possibility is with the finalName Element. The jar process uses the finalName and generate the jar with the correct name (specified by finalName) But the install process doesn't use the finalName. How can I achieve it that the install process (and of course the deploy process) also uses the finalName. Please help! TIA Martin Kuhn ++ Diese Nachricht ist vertraulich und ausschließlich für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollmächtigter sein, ist jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser Nachricht unzulässig. In diesem Fall bitten wir, den Absender umgehend zu benachrichtigen und die Nachricht zu vernichten. Elektronisch versandte Nachrichten können durch Unberechtigte manipuliert und/oder gelesen werden, weshalb jegliche Haftung hierfür ausgeschlossen wird. ++ This communication is confidential and is intended solely for the addressee(s). If you are not the intended recipient(s), his/her assistant, or authorized recipient, any form of disclosure, reproduction, distribution or any use of this communication or the information in it, is strictly prohibited and may be unlawful. In this case, please notify the sender immediately and destroy the e-mail. Electronic communication via the Internet by e-mail may be manipulated and/or read by third parties, thus we exclude any liability whatsoever for this e-mail. ++
Re: [m2] finalName in install and version for different environments
This is a bug we are hoping to fix shortly. While finalName can't be completely modified for installing in the repository, it should be possible to add a classifier for the environment. For reference, the JIRA bug is the one referring to attaching an artifact with a classifier via a profile. - Brett On 9/20/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have a project to build / deploy for three different enviroments (test,integration, production with different configs) and want to set the jar file name depending on the active profile. I know one possibility is with the finalName Element. The jar process uses the finalName and generate the jar with the correct name (specified by finalName) But the install process doesn't use the finalName. How can I achieve it that the install process (and of course the deploy process) also uses the finalName. Please help! TIA Martin Kuhn ++ Diese Nachricht ist vertraulich und ausschließlich für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte Adressat, einer seiner Mitarbeiter oder sein Empfangsbevollmächtigter sein, ist jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser Nachricht unzulässig. In diesem Fall bitten wir, den Absender umgehend zu benachrichtigen und die Nachricht zu vernichten. Elektronisch versandte Nachrichten können durch Unberechtigte manipuliert und/oder gelesen werden, weshalb jegliche Haftung hierfür ausgeschlossen wird. ++ This communication is confidential and is intended solely for the addressee(s). If you are not the intended recipient(s), his/her assistant, or authorized recipient, any form of disclosure, reproduction, distribution or any use of this communication or the information in it, is strictly prohibited and may be unlawful. In this case, please notify the sender immediately and destroy the e-mail. Electronic communication via the Internet by e-mail may be manipulated and/or read by third parties, thus we exclude any liability whatsoever for this e-mail. ++
