metadata_maven.xml
Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: metadata_maven.xml
Hi, Not sure to understand. Could you maybe rephrase a bit? Getting rid of maven-metadata.xml, if this is actually what you want, is quite impossible I think. But if this is what you ask for, could you explain a bit more why you came to think it would be a good idea? Cheers -- Baptiste Le 8 févr. 2013 11:50, Łukasz Tasz luk...@tasz.eu a écrit : Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: metadata_maven.xml
Hi, You understood exactly what I want. Currently I have issues with repository manager, it's not able to handle all deploys which are happening. On repository side metadata_maven.xml is ignored, and regenerated, and since deploys fails with metadata.xml I would like to remove it. Łukasz Tasz 2013/2/8 Baptiste MATHUS m...@batmat.net: Hi, Not sure to understand. Could you maybe rephrase a bit? Getting rid of maven-metadata.xml, if this is actually what you want, is quite impossible I think. But if this is what you ask for, could you explain a bit more why you came to think it would be a good idea? Cheers -- Baptiste Le 8 févr. 2013 11:50, Łukasz Tasz luk...@tasz.eu a écrit : Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Łukasz Tasz 2013/2/8 Baptiste MATHUS m...@batmat.net: Hi, Not sure to understand. Could you maybe rephrase a bit? Getting rid of maven-metadata.xml, if this is actually what you want, is quite impossible I think. But if this is what you ask for, could you explain a bit more why you came to think it would be a good idea? Cheers -- Baptiste Le 8 févr. 2013 11:50, Łukasz Tasz luk...@tasz.eu a écrit : Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - 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: metadata_maven.xml
Hi Łukasz, unfortunately you can't disable the deployment of the metadata... But what is the real problem with load on your repository manager server ? Really causing problems only by metadata ? Which RM do you use ? Kind regards Karl-Heinz Marbaise Original-Nachricht Datum: Fri, 8 Feb 2013 11:49:11 +0100 Von: Łukasz Tasz luk...@tasz.eu An: Maven Users List users@maven.apache.org Betreff: metadata_maven.xml Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - 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: metadata_maven.xml
Hi all, thanks a lot for answers, 2013/2/8 Karl Heinz Marbaise khmarba...@gmx.de: Hi Łukasz, unfortunately you can't disable the deployment of the metadata... and I will not write own workaround :) But what is the real problem with load on your repository manager server ? Generally I think I reached limit of of number artifacts that could be deployed at one time... Really causing problems only by metadata ? for sure not, metadata is one of artifact which is being deployed, and until main articact is deployed successfuly, and error occures when metadata is dpeloyed then whole transaction is failed - which is failing the build - that's why I thought about ignoring metadata at the beginning. Which RM do you use ? Until support doing a lot to solve this issue I would like to not make anti-advertisement :) regards L. Kind regards Karl-Heinz Marbaise Original-Nachricht Datum: Fri, 8 Feb 2013 11:49:11 +0100 Von: Łukasz Tasz luk...@tasz.eu An: Maven Users List users@maven.apache.org Betreff: metadata_maven.xml Hi All, I have simple question, can I somehow disable deployment of metadata_maven.xml? my repository manager cares for it bu it's own, so it causes unnecessary load - which is currently my problem... thanks in advance Łukasz Tasz - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New Maven idea: include (import++)?
Hello everyone, I see that, by including a pom in compile scope, the project has the dependencies defined as transitive dependencies in it's classpath. Two things come to my mind, which could make a scope include sensible: 1) dependency:analyze AKA define what you depend on for compilation - we use dependency:analyze and have a policy that projects should depend directly on stuff they need for compilation. - I have not checked this but by (ab)using a pom with compile scope, dependencies defined in there will trigger warnings from dependency:analyze, do they not? 2) using dependencies for other scopes - I think only dependencies declared in compile scope will be transitively in compile of the including project. - What if you always want to include junit, hamcrest and mockito (easymock ...) in scope test? Regards Mirko On Tue, Feb 5, 2013 at 4:29 PM, Laird Nelson ljnel...@gmail.com wrote: On Tue, Feb 5, 2013 at 6:10 AM, Matthew Adams matt...@matthewadams.mewrote: What I was looking for was a way to define a new artifact in a pom that, if used in a consuming artifact's dependencies, would include all of the dependencies in the referenced artifact. Hello; you can do this today by simply declaring a normal dependency on an artifact of type pom. So: dependency groupIdyour.datanucleus.pom.groupId/groupId artifactIdyour.datanucleus.pom.artifactId/artifactId versionwhatever/version scopecompile/scope typepom/type /dependency You should not feel like you missed something; this is not really explained well anywhere. You kind of have to infer it from other parts of the Maven documentation. There are several side effects to doing things this way, which may or may not matter to you. First, the dependencies are one level down--that is, you didn't include your pom artifact's dependencies directly, you included them transitively. This might have a bearing on what versions of a given dependency win in a complex inherited pom scenario. Second, I'm just frankly not sure how (or if) the dependencyManagementsection in the pom-as-dependency will work, if at all. I hope this helps. Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: metadata_maven.xml
Hi Łukasz, without the full information it's hard to guess what's wrong...my glass bulp is under maintenance ;-) Generally I think I reached limit of of number artifacts that could be deployed at one time... What does this mean? The limit of the number of artifacts ? I can't believe that ... Which RM do you use ? Until support doing a lot to solve this issue I would like to not make anti-advertisement :) It's not the point to discuss positve or negative it's the intention to solve the problem...and of course it would be interessting for the companies to know if something is going wrong... Artifactory, Nexus, Archiva ? Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem reusing specific plugin executions with profiles
Yeah, I didn't do anything special to get XML to render. I remember problems in the past, but forgot and just blindly pasted into the nabble text editor from my local text editor... I'm actually quite dumb. Just ask my wife. ;) -- View this message in context: http://maven.40175.n5.nabble.com/Problem-reusing-specific-plugin-executions-with-profiles-tp5746276p5746372.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: Problem reusing specific plugin executions with profiles
stephenconnolly wrote 1. Congratulations on successfully posting XML from Nabble. Until now, I genuinely did not think it was possible (as evidenced by the many many posts via Nabble where the xml is stripped). I take your success as an indication that you are a smart guy with some technical savvy Yeah, nothing special there. Copy/paste/worky. stephenconnolly wrote 2. Maven is an opinionated build tool. It really loves to build environment agnostic artifacts, and it thinks its job is finished when those environment agnostic artifacts have been deployed into a Maven Repository. ACK stephenconnolly wrote 3. You are building something SaaS-like, so your application requires configuration for the environment into which it will be deployed. Maven does not really have a good story for these stages in the application life cycle (since they take place after the environment agnostic artifact has been deployed to a maven repository). I think you misunderstand my intent. My build contains integration tests which must execute successfully against various ORM, database, and jdbc driver combinations. The artifacts that are built are indeed environmentally agnostic. For example, my domain artifact, which contains my persistent JPA entities, has a Spring context file that simply requires an EntityManagerFactory; where that comes from doesn't matter to my entities. As long as its present in the Spring configuration, the domain component is good to go. stephenconnolly wrote The closest to a good story is to create a separate module for each destination environment and repackage the environment agnostic artifact in those modules... Better is to use DevOps toolchains to handle this DevOps style task (think chef/puppet) Please read my answer to a similar question on stack overflow: http://stackoverflow.com/questions/14650468/whats-a-practicable-way-for-automated-configuration-versioning-and-deployment/14661186#14661186 Yeah, that may be true in some cases, but not mine. stephenconnolly wrote The TL;DR is that profiles are not really aimed for use in your use case. Yes you can use them, but you probably shouldn't and you will fight maven the whole way. Please read the above carefully, if you still are 100% certain that profiles are the only solution to your problem, then maybe we can take a look at where things are going wrong... But my earnest belief is that you are heading down a path towards hating maven, and I'd rather try and help you off that path rather than find the obscure tweak needed to help you further down the path you are on -Stephen Maven profiles suit this task just fine, IMHO. I could have created a generic/contrived/artificial foobar-style example to demonstrate the crux of the issue, but I was too lazy. Please don't let my particulars intent cloud the issue at hand, which is why all executions of a plugin, defined in the pom parent, are being executed when only certain execution ids are being specified in the child pom. I'm not a maven newbie. I'm just using it in a sophisticated way as a responsible adult, aware of the tradeoffs. I appreciate your concern. Now, on to the issue at hand. Can anyone tell me why all executions from the parent pom plugin are being executed in the child pom, even though the child is only referencing some of the parent's executions? Thanks, Matthew -- View this message in context: http://maven.40175.n5.nabble.com/Problem-reusing-specific-plugin-executions-with-profiles-tp5746276p5746373.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
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
Why is the functionality of the all attribute of the RequireActiveProfile rule commented out?
I'm trying to use the requireActiveProfile rule via the
maven-enforcer-plugin, version 1.2:
=
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version${app.maven-enforcer-plugin.version}/version
executions
execution
idrequire-orm-profiles/id
goals
goalenforce/goal
/goals
configuration
rules
requireActiveProfile
profileshibernate,datanucleus/profiles
*/allfalse/all/*
/requireActiveProfile
/rules
/configuration
/execution
/executions
/plugin
=
It doesn't work, and here, apparently is why: the code that uses the all
attribute on the class RequireActiveProfile is commented out (downloaded
from
http://search.maven.org/remotecontent?filepath=org/apache/maven/enforcer/enforcer-rules/1.2/enforcer-rules-1.2-sources.jar).
=
public class RequireActiveProfile
extends AbstractNonCacheableEnforcerRule
{
/** Comma separated list of profiles to check. */
public String profiles = null;
/** If all profiles must be active. If false, only one must be active */
public boolean all = true;
/*
* (non-Javadoc)
*
* @see
org.apache.maven.enforcer.rule.api.EnforcerRule#execute(org.apache.maven.enforcer.rule.api.EnforcerRuleHelper)
*/
public void execute( EnforcerRuleHelper theHelper )
throws EnforcerRuleException
{
ListString missingProfiles = new ArrayListString();
try
{
MavenProject project = (MavenProject) theHelper.evaluate(
${project} );
if ( StringUtils.isNotEmpty( profiles ) )
{
String[] profs = profiles.split( , );
for ( String profile : profs )
{
if ( !isProfileActive( project, profile ) )
{
missingProfiles.add( profile );
}
}
boolean fail = false;
if ( !missingProfiles.isEmpty() )
{
fail = true;
*
// if (all missingProfiles.size() != profs.length)
// {
// fail = true;
// }
// else
// {
// if (!all missingProfiles.size() = (profs.length
-1))
// {
// fail = true;
// }
// }
*
}
if ( fail )
{
StringBuilder buf = new StringBuilder();
if ( message != null )
{
buf.append( message + \n );
}
for ( String profile : missingProfiles )
{
buf.append( Profile \ + profile + \ is not
activated.\n );
}
throw new EnforcerRuleException( buf.toString() );
}
}
}
catch ( ExpressionEvaluationException e )
{
throw new EnforcerRuleException( Unable to retrieve the
project., e );
}
}
// ...
=
I saw https://jira.codehaus.org/browse/MENFORCER-143 and it says this was
fixed in 1.1.1. What gives?
/NB: I can't seem to find where the svn repo is that contains
RequireActiveProfile.java, which is why I used the maven repo search link./
Thanks,
Matthew
--
View this message in context:
http://maven.40175.n5.nabble.com/Why-is-the-functionality-of-the-all-attribute-of-the-RequireActiveProfile-rule-commented-out-tp5746380.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: Why is the functionality of the all attribute of the RequireActiveProfile rule commented out?
Matthew Adams wrote/ NB: I can't seem to find where the svn repo is that contains RequireActiveProfile.java, which is why I used the maven repo search link. / Found it at https://svn.apache.org/repos/asf/maven/enforcer. Still, what gives? Why is it commented out? -- View this message in context: http://maven.40175.n5.nabble.com/Why-is-the-functionality-of-the-all-attribute-of-the-RequireActiveProfile-rule-commented-out-tp5746380p5746386.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: 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 reusing specific plugin executions with profiles
If you then need the executions in the root and only some children... put the executions in pluginManagement in the root but without calling out any goals. Repeat the executions in plugins in the root, calling out the goals for those to execute and specifying inheritedfalse/inherited and then finally repeat for the child projects I doubt that solves his problem. He wants to be able to specify from the command line which profiles to utilize during this specific build of a given module -- so editing poms etc is not going to interest him. I could be wrong though. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[SOLVED] Re: Problem reusing specific plugin executions with profiles
stephenconnolly wrote If you then need the executions in the root and only some children... put the executions in pluginManagement in the root but without calling out any goals. Repeat the executions in plugins in the root, calling out the goals for those to execute and specifying inherited false /inherited and then finally repeat for the child projects That did the trick! Thanks -- I don't think I would've guessed that one. Now, the configurations are all in one place. Nice! -matthew -- View this message in context: http://maven.40175.n5.nabble.com/Problem-reusing-specific-plugin-executions-with-profiles-tp5746276p5746396.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: Problem reusing specific plugin executions with profiles
Wayne Fay wrote If you then need the executions in the root and only some children... put the executions in pluginManagement in the root but without calling out any goals. Repeat the executions in plugins in the root, calling out the goals for those to execute and specifying inherited false /inherited and then finally repeat for the child projects I doubt that solves his problem. He wants to be able to specify from the command line which profiles to utilize during this specific build of a given module -- so editing poms etc is not going to interest him. I could be wrong though. The reason it solved my problem was because I specify via the command line the profiles I want to activate, then, in the pom's profile sections, I configure the particular plugin executions I want in the child pom's projectprofilesprofileid.../idbuildplugins section. -matthew -- View this message in context: http://maven.40175.n5.nabble.com/Problem-reusing-specific-plugin-executions-with-profiles-tp5746276p5746397.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: 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:;
Re: MRM inside Eclipse
Am 07.02.2013 21:43, schrieb Curtis Rueden: Just in case you didn't see it already, the following page of the M2E documentation explains (rather obtusely) in detail about how to configure M2E's lifecycle mappings to work with various Maven plugins: http://wiki.eclipse.org/M2E_plugin_execution_not_covered There is actually a lot of goodness buried in that page if you read carefully (e.g., the hint about using the ignore quickfix then changing it to execute). Yep, that's what I did. Re-read it twice, and I think I understand it now. This is getting pretty off-topic for this list though, seeing as there is an M2E-specific list as well. Agreed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Reading Variables From a Properties File Without Creating An Ouptut File
I am developing a Maven plugin. It will search for given token and inject
values at given files. Everything is OK but there is only one thing that I
am struggling with. I have some tokens and variables and I want to read them
from a properties file. For example:
project.version = ${project.version}
svn.revision.number = ${svn.revision.number}
bamboo.build.number = ${bamboo.build.number}
foo=bar
If I write them into my pom.xml file Maven will understand that variables
and when I get the value of them within my Mojo Maven will automatically
give me the value of variable. However if I write them into a properties
file it doesn't.
I have realized resource tag and tried:
resources
resource
directorysrc/main/resources//directory
filteringtrue/filtering
/resource
/resources
but it is not what I want. I have tried to that at my Mojo:
MavenResourcesExecution mavenResourcesExecution = new
MavenResourcesExecution(resources, outputFileDirectory, project, encoding,
buildFilters, Collections.StringemptyList(), session);
try {
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
} catch (MavenFilteringException e) {
e.printStackTrace();
}
but because of I pass outputFileDirectory it creates a new properties file
into that directory. I don't want to get a new filtered properties file I
just want to retrieve a properties variable that includes replaced with real
values of Maven variables from my original properties file.
If I don't create a outputdirectory and just I can do something like that:
Properties filteredProperties =
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
everything will be OK for me. How can I do that?
PS: Something like ${project.version} I call them as Maven variables.
--
View this message in context:
http://maven.40175.n5.nabble.com/Reading-Variables-From-a-Properties-File-Without-Creating-An-Ouptut-File-tp5746409.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: Reading Variables From a Properties File Without Creating An Ouptut File
Hi,
On Fri, Feb 8, 2013 at 10:00 PM, kamaci furkankam...@gmail.com wrote:
I am developing a Maven plugin. It will search for given token and inject
values at given files.
That sound exactly like something the maven-resource-plugin can do.
Everything is OK but there is only one thing that I
am struggling with. I have some tokens and variables and I want to read
them
from a properties file. For example:
project.version = ${project.version}
svn.revision.number = ${svn.revision.number}
bamboo.build.number = ${bamboo.build.number}
foo=bar
If I write them into my pom.xml file Maven will understand that variables
and when I get the value of them within my Mojo Maven will automatically
give me the value of variable. However if I write them into a properties
file it doesn't.
Have you looked at
http://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html#filters
and maybe
http://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html
?
I have realized resource tag and tried:
resources
resource
directorysrc/main/resources//directory
filteringtrue/filtering
/resource
/resources
but it is not what I want. I have tried to that at my Mojo:
MavenResourcesExecution mavenResourcesExecution = new
MavenResourcesExecution(resources, outputFileDirectory, project, encoding,
buildFilters, Collections.StringemptyList(), session);
try {
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
} catch (MavenFilteringException e) {
e.printStackTrace();
}
but because of I pass outputFileDirectory it creates a new properties file
into that directory. I don't want to get a new filtered properties file I
just want to retrieve a properties variable that includes replaced with
real
values of Maven variables from my original properties file.
If I don't create a outputdirectory and just I can do something like that:
Properties filteredProperties =
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
everything will be OK for me. How can I do that?
PS: Something like ${project.version} I call them as Maven variables.
--
View this message in context:
http://maven.40175.n5.nabble.com/Reading-Variables-From-a-Properties-File-Without-Creating-An-Ouptut-File-tp5746409.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
--
Adrien Rivard
06 63 08 79 74
Re: Reading Variables From a Properties File Without Creating An Ouptut File
copy resources requires an output directory that is what I don't want. However I didn't check to implement a custom filter, do I need copy resources plugin to it. I don't want to use copy resources plugin because I am developing a plugin myself that has lightweights of some plugins. Is there any example how to make a custom filter so I don't write the output to a file and return a Properties variable from that filter? -- View this message in context: http://maven.40175.n5.nabble.com/Reading-Variables-From-a-Properties-File-Without-Creating-An-Ouptut-File-tp5746409p5746427.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
Reading Variables From a Properties File Without Creating An Ouptut File
I am developing a Maven plugin. It will search for given token and inject
values at given files. Everything is OK but there is only one thing that I
am struggling with. I have some tokens and variables and I want to read them
from a properties file. For example:
project.version = ${project.version}
svn.revision.number = ${svn.revision.number}
bamboo.build.number = ${bamboo.build.number}
foo=bar
If I write them into my pom.xml file Maven will understand that variables
and when I get the value of them within my Mojo Maven will automatically
give me the value of variable. However if I write them into a properties
file it doesn't.
I have realized resource tag and tried:
resources
resource
directorysrc/main/resources//directory
filteringtrue/filtering
/resource
/resources
but it is not what I want. I have tried to that at my Mojo:
MavenResourcesExecution mavenResourcesExecution = new
MavenResourcesExecution(resources, outputFileDirectory, project, encoding,
buildFilters, Collections.StringemptyList(), session);
try {
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
} catch (MavenFilteringException e) {
e.printStackTrace();
}
but because of I pass outputFileDirectory it creates a new properties file
into that directory. I don't want to get a new filtered properties file I
just want to retrieve a properties variable that includes replaced with real
values of Maven variables from my original properties file.
If I don't create a outputdirectory and just I can do something like that:
Properties filteredProperties =
mavenResourcesFiltering.filterResources(mavenResourcesExecution);
everything will be OK for me. How can I do that?
PS: Something like ${project.version} I call them as Maven variables.
--
View this message in context:
http://maven.40175.n5.nabble.com/Reading-Variables-From-a-Properties-File-Without-Creating-An-Ouptut-File-tp5746403.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: Reading Variables From a Properties File Without Creating An Ouptut File
I need something like that. When Maven checks the pom.xml if it sees
variables it gets their value. I need something like that:
String version = something.getProperty(project.version) // to get
${project.version}
String revision = something.getProperty(svn.revision.number) // to get
${svn.revision.number}
Does it can be done via a custom filter?
--
View this message in context:
http://maven.40175.n5.nabble.com/Reading-Variables-From-a-Properties-File-Without-Creating-An-Ouptut-File-tp5746409p5746431.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
