Re: [VOTE] Retire Maven Reactor Plugin
+1 On 22.03.2014, at 22:52, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, based on the decision we have made on the 18. february 2014 to define End Of Life of Maven 2 http://maven.apache.org/maven-2.x-eol.html I would suggest to retire the Maven Reactor Plugin. The last release has been made on 23rd of september 2008 version 1.0. Apart from that the complete functionality is now part of Maven 3. I therefor propose that we retire maven-foo-plugin. If this vote is successful I will make one final release of the plugin, making it clear on the plugin site that it has been retired. After that the source code will be moved into the retired area in Subversion. The process for retiring a plugin is described here: http://maven.apache.org/developers/retirement-plan-plugins.html The vote is open for 72 hours. [ ] +1 Yes, it's about time [ ] -1 No, because... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
properties that are not being resolved
I stumbled over some rather strange behaviour regarding properties. It
seems properties generated by one plugin are not always resolved for other
plugins and I can't figure out why.
I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins. The particular plugin
does not seem important, but I've included it here for sake of completeness:
plugin
groupIdcom.code54.mojo/groupId
artifactIdbuildversion-plugin/artifactId
version1.0.3/version
configuration
tstamp_format.MM.dd HH:mm/tstamp_format
/configuration
executions
execution
goals
goalset-properties/goal
/goals
/execution
/executions
/plugin
But when I referenced the properties set by the plugin in an env entry for
the maven ear plugin, the properties were not resolved at all:
envEntries
env-entry
descriptionMiddleware build information/description
env-entry-namejava:app/env/sw-version/env-entry-name
env-entry-typejava.lang.String/env-entry-type
env-entry-value${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}/env-entry-value
/env-entry
/envEntries
Just to be sure, I used the latest maven and tried both version 2.9 of the
plugin and the latest from the repo with the same result.
The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in GenerateApplicationXmlMojo.execute():
// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
for (PlexusConfiguration entry : entries) {
if (env-entry.equals(entry.getName())) {
PlexusConfiguration[] envEntryChildren = entry.getChildren();
if (envEntryChildren != null) {
for (PlexusConfiguration envEntryChild : envEntryChildren) {
envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
}
}
}
}
}
Then it worked just fine, but I don't understand why this is necessary. I
thought whatever called the plugin was supposed to have done the variable
substitution already. So clearly the properties were present at the time
of executing the plugin, but they werent being automaticly substituted.
To add to the confusion, using ${project.version} in the env-entry-value
was resolved just fine, but just not the properties coming from another
plugin despite the plugins being run in the correct order.
To further add to the confusion, I then used maven ant-run plugin, echoing
the values of properties which worked just fine (!)
While I solved the problem for me by making a locally patched version of
the ear plugin, it's not really a solution I favour, so I hope someone can
provide a better and more permanent fix.
Regards,
Henrik Gram
centralized settings.xml vs local question
Hi, I am a strong advocate of maven Archiva where I administer our departments archiva svn and site server server where we use maven to build/release stuff. I don't claim to be an expert in the field (but I am not completely dumb either when it comes to this :) - so if my question is silly please don't knock me to bad :) The way we currently go about setting up new developers centers around the following... Each developer ensure they configure their client to point to a set maven release (currently 3.0.4) Each developer will then have a unique personal account created in archiva giving them the appropriate access to release or not As part of this I manually encrypt this archiva user psw using mvn --encrypt-password arg where I create a tailored settings.xml where I add the encrypted password to each repo they are meant to have release access to (all developers can access resources to do local builds as guest - but only authorized users can do official releases *(prod state) ) The problem I have with this is 1. many settings.xml to manage 2. problems or global changes may affect every single developer resulting in that I need to roll out new settings.xml to each developers. My simply question is ... Can this be centralized somehow meaning that the clients settings.xml somehow refers to groups located on the remote archiva server If this were possible I would cut down the maintenance and remove the hassle of distributing tailored settings.xml when people come on board. I can not accept a scenario where each developer uses the same global credentials cheers -- View this message in context: http://maven.40175.n5.nabble.com/centralized-settings-xml-vs-local-question-tp5789050.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
search.maven.org is missing results
I want to be able to find com.earldouglas/xsbt-web-plugin via search.maven.org, but am having trouble doing so. When I search for xsbt-web-plugin, I only get older results from the GroupId com.github.siasia. http://search.maven.org/#search|ga|1|xsbt-web-plugin Furthermore, when I search for com.earldouglas, the set of results is missing many entries for the GroupId com.earldouglas: http://search.maven.org/#search|ga|1|com.earldouglas This can be verified by browsing the com.earldouglas/ GroupId: http://search.maven.org/#browse|1101551570 Am I doing something wrong? Why are so many results apparently missing? Note that these artifacts are all hosted on Maven Central. Thanks! James
