Re: Attached artifacts and dependencies
I think the use case is where you need to give a client lib to 3rd parties not using maven, otherwise the dependency issue will kill you unless you are doing this from an api-only module On Saturday, 5 January 2013, Stanimir Stamenkov wrote: Sat, 5 Jan 2013 23:52:50 +0100, /Anders Hammar/: I always argue for having the API (e.g. ejb client) as a separate module and then the impl (e.g. the ejb) as a separate module. That's what we're using after all, but I've recently discovered this ejb-client option and started wondering if there's something I'm missing about how things are supposed to work/be used. -- Stanimir --**--**- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[doap-plugin] shortdesc property value not interpolated?
Hi all guys,
I am tryin' to plug the doap-plugin in Apache Onami and I noticed a
strange behaviour of the `shotdesc` property.
If not specified, the plugin terminates with an error:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by ASF.
If I specify as
doapOptions
shortdesc${project.description}/shortdesc
/doapOptions
it terminates with the same error message:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by ASF.
If I set a value, such as
doapOptions
shortdescBazinga!/shortdesc
/doapOptions
It goes ok.
Ah, and yes, the ${project.description} property is specified :)
Is there something I overlooked or maybe a known issue?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven versioning
We started by bumping all the versions but there is really no point and we stopped when our module count reached yours. Maven documents the versions of the dependencies in the pom so you really don't need to make everything match. We had a simple control sheet where we documented what each version of out app used for each module. Once you get into production and are issuing releases where only a few modules are changing on each release, the amount of time spent updating and testing new releases of modules that did not change and only required a pom update and a rebuild, was just not worth it. We figured that if we could build with the same version of an Apache module, we could build with the same version of one of our libraries if it did not change. Ron On 04/01/2013 10:09 AM, tc78 wrote: I am currently working with a group that is migrating a group of applications and libraries to Maven. I can’t seem to find the best way to handle the POM versioning so I thought I would bounce that off those of you with more experience. There are roughly 20 web apps and 10 libraries. What I am wondering is if I have a new version of a web app coming out, is it best to bump up the version on the app’s pom.xml as well as the dependency poms’ versions or is it standard for each library to increment on its own. Say for instance I implement someApp 1.1 and I now need to have a bug fix for someDependency. Does that make the next deployed version of someApp 1.1.1 or does that just bump up the version of someDependency? Most of the work I did previously with Maven was working with SNAPSHOTs so after I am trying to wrap my head around the versioning management portion of it. Thanks! -- View this message in context: http://maven.40175.n5.nabble.com/Maven-versioning-tp5741895.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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Manifest
you cannot. On Sat, Jan 5, 2013 at 5:58 PM, Rajwinder Makkar rmakkaroff...@gmail.comwrote: Hi, Here is the scenario : - I want to insert property and value pair in maven artifact manifest file. - I understand there are maven plugins where i can modify manifest like Maven Archiver. - But above requires development team to mention things in POM which sometimes is difficult to preach in big organization. Question is : How can i pass property/value pair a part of maven build process on the command line which insert things in manifest file ? Something like mvn clean install --manifestdefineproperty property=value -raj
Re: copy selected dependencies transitively
If each sub-pipeline is a separate artifact with very little in common with other sub-pipelines (I assume that there are common libraries through the whole pipeline.), then is does not seem to be a bad idea to have a project for each sub-pipeline. A good IDE (Eclipse/STS for example) gets rid of most of the overhead once you set up your poms. The SVN management is transparent. We built an LMS with over 70 separate modules and did not find the project management to be very onerous. Ron On 05/01/2013 11:22 AM, Erik Fäßler wrote: Hello Ron, very valid and good point, thank you. I will describe my scenario: I have a pipeline of processing steps. Each step is performed by a component which is packaged into a maven artifact. As the components have been developed independently of each other, some of them share some dependencies - in different and possibly incompatible versions, however. Thus, I want to cut down the pipeline to sub-pipelines with non-colliding dependencies of the used components. Then, I can run the sub-pipelines in the correct order, each in its own JVM and the exact dependencies necessary. Each sub-pipeline operates on data stored in a database, modifies the data, and stores it back. This way the original pipeline can be broken down to these sub-pipelines. Still, the project I have in mind stores all parts which are necessary to perform the complete original pipeline. I could, of course, create a maven project for each sub-pipeline. But this would come with quite some overhead in the project management (multiple POMs with similar configurations, multiple projects in SVN which must be maintained and - for running - all checked out in a single manner...). So my thought was to just create lib-folders for the component artifacts used in each sub-pipeline. And for this I thought the copy-dependencies plugin could help me if I just could tell it to copy the dependencies of each component in its own folder (or one folder for multiple components forming a sub-pipeline). I hope that was understandable :-) Any ideas how I could reach my goals without turning to a complete new technology (OSGi or something)? I don't need the sub-piplines to run in parallel (on the contrary!), I just need the dependencies of each sub-pipeline in folders of their own. Thanks a lot for reading and helping! Erik Am 04.01.2013 um 21:57 schrieb Ron Wheeler rwhee...@artifact-software.com: What are you actually trying to do? Why do you need to do this? What makes your environment different from everyone else's operation? Perhaps there are easier ways to get what you want by reformulating the problem. Ron On 04/01/2013 11:17 AM, Erik Fäßler wrote: Hi all, my issue is no new one and I found some related posts - even on this list - already. But none of them has been answered, so I try my luck. What I want: Copy one (or multiple) selected dependency of my project into a directory of its own. That is, unlike the normal copy-dependencies execution which just copies all dependencies into a directory, I want to select only some of them. I tried it with includeArtifactIds like this: plugin artifactIdmaven-dependency-plugin/artifactId version2.6/version executions execution idCopy dependencies transitive/id phasepackage/phase goals goalcopy-dependencies/goal /goals configuration excludeTransitivefalse/excludeTransitive outputDirectorylib/outputDirectory includeArtifactIdsmyartifact/includeArtifactIds /configuration /execution /executions /plugin But here, the original meaning of includeArtifactIds is copy exactly the artifacts of the given IDs, nothing else, which also means that no transitive dependencies are copied. I stated explicitly excludeTransitivefalse/excludeTransitive but this seems to be ignored. Question: Is there another way to achieve what I need (copy selected artifacts along with their transitive dependencies into a folder of their own). Feature Request: I guess it wouldn't be too difficult to take the excludeTransitivefalse/excludeTransitive command into account and just copy the transitive dependencies in this case, would it? If this could be added, it would help me and I guess some other people out there.
Re: Manifest
Sat, 5 Jan 2013 14:58:45 -0800, /Rajwinder Makkar/:
How can i pass property/value pair a part of maven build process on the
command line which insert things in manifest file ? Something like mvn
clean install --manifestdefineproperty property=value
Note, depending on the purpose of this property you might not be
doing something considered a good practice, but I can say from the
description you've given.
On the command-line you should be able to set a system property like:
mvn -Dproperty=value ...
and then refer ${property} in the archive configuration. One should
be able to set the necessary property in his settings.xml [1], in
a profile active by default [2], also. In any case, you might want
to add enforcer configuration to verify the necessary property has
been set:
http://maven.apache.org/enforcer/maven-enforcer-plugin/
http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
[1] http://maven.apache.org/settings.html#Properties
[2] http://maven.apache.org/settings.html#Activation
--
Stanimir
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Manifest
Sun, 06 Jan 2013 23:46:05 +0200, /Stanimir Stamenkov/: Note, depending on the purpose of this property you might not be doing something considered a good practice, but I can say from the description you've given. I've really meant to say: ... but I *can't* say from the description you've given. -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Release Plugin 2.4 Released
Hey all,
First day back at work and first up we're doing a release - at the end of
the year I'd bumped our poms to use the 2.4 plugin but never did any
releases, and now - I find it appears to be broken with git.
In my release config we have:
pushChangesfalse/pushChanges
localCheckouttrue/localCheckout
however, when release:perform runs, the mojo tries to clone from the REMOTE
repository which doesn't have the new tag, dropping back to 2.3.2 and
everything works fine and we can release.
Is this a known issue?
--
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree
On Wed, Dec 19, 2012 at 12:04 PM, Robert Scholte rfscho...@apache.orgwrote:
The Apache Maven team is pleased to announce the release of the Maven
Release Plugin, version 2.4
This plugin is used to release a project with Maven, saving a lot of
repetitive, manual work. Releasing a project is made in two steps: prepare
and perform.
http://maven.apache.org/**plugins/maven-release-plugin/http://maven.apache.org/plugins/maven-release-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-release-**plugin/artifactId
version2.4/version
/plugin
Release Notes - Maven 2.x Release Plugin - Version 2.4
** Bug
* [MRELEASE-186] - Active profiles are not carried through into the
release descriptor
* [MRELEASE-260] - Profiles given on command-line not added to
exec.additionalArguments
* [MRELEASE-415] - Plugin fails to activate profiles in submodules.
* [MRELEASE-459] - releaseProfiles has no effect without passing
profiles in the command line
* [MRELEASE-511] - release:prepare Error parsing version, cannot
determine next version: Unable to parse the version string when running in
batch mode.
* [MRELEASE-571] - When collecting active profiles, the active
profiles from parent poms are not considered
* [MRELEASE-614] - releaseProfiles works only if at least one
(default) profile is activated in the same pom.xml
* [MRELEASE-619] - release:branch doesn't work as expected with
multi-module projects
* [MRELEASE-667] - Profiles activated in settings.xml can't be
deactivated for release
* [MRELEASE-750] - String index out of range: -1 in
ReleaseUtils.**loadResolvedDependencies()
when using Parent-Module-Layout
* [MRELEASE-755] - When passing arguments to underlying maven
executions not all maven options are accepted
* [MRELEASE-772] - mvn release:prepare fails with IOException and a
write error (Access is denied)
* [MRELEASE-775] - IllegalStateException while checking for
modifications if multiple exclusion patterns match
* [MRELEASE-785] - Arguments containing spaces and quotes cause the
forked maven process to fail
* [MRELEASE-786] - -Darguments doesn't allow -T to be passed to forked
builds for multi threading
* [MRELEASE-787] - release:prepare-with-pom fails when
suppressCommitBeforeTag is used (SVN)
* [MRELEASE-795] - Wrong level when using release:branch
* [MRELEASE-808] - Can't generate release-pom.xml when custom
finalName contains ${project.version}
** Improvement
* [MRELEASE-559] - Clarify parameter documentation for release:branch
* [MRELEASE-734] - When releaseVersion and developmentVersion are
passed in command-line but are empty should be treated as not-defined
* [MRELEASE-783] - release:update-versions should not need SCM config
* [MRELEASE-796] - Add AbstractScmReleaseMojo
** New Feature
* [MRELEASE-592] - Please allow de-activation of profiles
** Task
* [MRELEASE-776] - use maven-plugin-tools' java 5 annotations
Enjoy,
-The Apache Maven team
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Embedded java 6 librairies
Hello all, I my application I have following jar declared as a Maven dependencies: serializer.jar, xercesImpl-2.8.1.jar, jaxb-api.jar, jaxb-impl.jar, saaj.jar But I think some of them are already included in rt.jar ? Can you tell me so that I do not exclude dependencies if they aren't already present in java 6 ? Best regards, Adrien
