they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.
/Anders
On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 13 February 2013 15
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in_Lifecycle_Bindings
Have a look at the war lifecycle, you'll see that there is only one goal
that does the copying from src/main/webapp to target/${finalName} and that
is the war:war goal which does the copy
What you want to do is move the css out of src/main/webapp to e.g.
src/processed/webapp
Then you bind the groovy step for processing to the prepare-package phase
(or any earlier one either) putting the processed files in
target/generated-webapp/groovy/... and use
You need to ask the Axis2 people, their PMC is responsible for their brand.
On 12 February 2013 09:16, adrien ruffie adriennolar...@hotmail.fr wrote:
Hello All,
In my company we have checkout and modified
One class of org.apache.axis2:axis2-transport-http:1.5.1
We repackage it as a
That is the An alternative is to use a second webapp module to do the CSS
processing between the exploding and repacking steps. route I suggested
On 12 February 2013 10:31, Cagecurrent p...@cagecurrent.com wrote:
Thanks for your help! :)
I guess another solution would be to modify the CSS
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
\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
Please take a couple of minutes to read my answer to a very similar
question on stack overflow
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
It should hopefully make things a little clearer
-Stephen
On Thursday, 7 February 2013,
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
2. Maven is an
See in-line
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
Am 06.02.2013 17:47, schrieb Manfred Moser:
I dont think there is a real MRM type of functionality in M2e ... kind of
doesnt make sense to me either. A MRM is a server software while M2e is a
development environment.
m2e
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
Am 06.02.2013 19:57, schrieb Stephen Connolly:
See in-line
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
Am 06.02.2013 17:47, schrieb Manfred Moser:
I dont think there is a real MRM type of functionality in M2e ... kind
That's the lucene index of the maven repository. No content, just an index
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
Am 06.02.2013 20:38, schrieb Stephen Connolly:
On Wednesday, 6 February 2013, Joachim Durchholz wrote:
Am 06.02.2013 19:57, schrieb Stephen Connolly:
See
If these dependencies are OSS just upload them to central.. Even under your
own groupId if you feel uncomfortable pushing under the originating
projects gId
On Wednesday, 6 February 2013, Toolforger wrote:
Am 06.02.2013 21:19, schrieb Baptiste MATHUS:
2013/2/6 Toolforger
[/Apache hat]
[CloudBees hat]
If you *really* just want to get a Maven repo up and running, just sign up
for a CloudBees account. That will give you a WebDAV file share that you
can use as a Maven repository. Not as good as a MRM, but it's free and it's
not a SCM (ab)used into being a Maven
It is a version range.
The [ and ] brackets indicate inclusive end-points, while ( and ) are
exclusive end points, so
[2.3.19 means =2.3.19
2.4) means 2.4
However, due to how versions are compared, there can be strange versions
that creep into the range.
My recommendation is to add an
Note that you don't need to add the comments (or even the exclusion) but
these help you later on decipher the intent
On 5 February 2013 13:05, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
It is a version range.
The [ and ] brackets indicate inclusive end-points, while
Slightly OT.
Why are you using argLine which is for things like JVM memory options
(think -Xmx512m) and not
http://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#systemPropertyVariablesfor
setting the system properties in surefire/falsesafe's forked JVMs?
You may have
Also the it.test property is parsed by the Mojo and normally not passed
through to the surefire engine. IOW the Maven plugin uses that property to
decide what tests to ask for running.
On 5 February 2013 13:51, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
Slightly OT.
Why are you
On Thursday, 31 January 2013, Tonio Caputo wrote:
I'm using maven release for a release procedure, following this workflow
1 - release:branch create a release candidate
using version X.X.X-000-SNAPSHOT
(000 stands for build number)
2 - release:prepare release:stage to deploy the
On 30 January 2013 08:30, Joachim Durchholz j...@durchholz.org wrote:
Am 30.01.2013 00:22, schrieb Stephen Connolly:
On 29 January 2013 22:22, Joachim Durchholz j...@durchholz.org wrote:
Am 29.01.2013 21:09, schrieb Stephen Connolly:
On Tuesday, 29 January 2013, Joachim Durchholz wrote
There are two ways to look at this:
1. Maven is what it is, how do I achieve my end goal as close as is
practicable to the maven best practices
2. Maven sucks, and here is how it should do things differently.
We appreciate both types of viewpoint, but keep in mind that it has taken
*over a
Nooo. Please not that
On Tuesday, 29 January 2013, Jeremy Long wrote:
One solution I've seen people use is outlined here:
http://blog.dub.podval.org/2010/01/maven-in-project-repository.html
--Jeremy
On Tue, Jan 29, 2013 at 11:16 AM, Kristian Lind
klpc...@gmail.comjavascript:;
wrote:
On Tuesday, 29 January 2013, Joachim Durchholz wrote:
Am 29.01.2013 19:42, schrieb Anders Hammar:
The right/correct solution here is to setup an internal Maven repository
where you deploy those jars to.
I still feel very uneasy about that, and I think I can pinpoint the reason
a bit
On 29 January 2013 22:22, Joachim Durchholz j...@durchholz.org wrote:
Am 29.01.2013 21:09, schrieb Stephen Connolly:
On Tuesday, 29 January 2013, Joachim Durchholz wrote:
Am 29.01.2013 19:42, schrieb Anders Hammar:
The right/correct solution here is to setup an internal Maven
My rule of thumb.
If you only need the value in one place... Don't use a property, they cause
more trouble than they're worth
If you need the same value in two or more places, the problems with
properties are less than the risk of being out of sync, so use the property.
On Saturday, 26 January
On Thursday, 24 January 2013, Joachim Durchholz wrote:
Am 24.01.2013 05:39, schrieb Ron Wheeler:
You manually put the jars in your Maven repo through its manual upload
procedure with some version number (nice if it relates to the version
that the authors gave them) and reference them as
If you are either replacing the (empty) jar with your real jar in the
package phase of your 13 projects without source,
And with the disclaimer that we don't like this way and prefer the MRM +
simple shell script to do the mvn deploy:deploy-file, but understand your
needs, you should be ok
Note
I assume you are renaming it to
nar-maven-plugin
To remove the confusion and clarify that this is not a plugin originating
from the maven project
-Stephen
On Friday, 18 January 2013, Tim Astle wrote:
Thanks for the clarification.
I posted to this mailing list because that's what is listed
On Friday, 18 January 2013, Maven User 3150...@gmail.com wrote:
We produce a large application from the artifacts of 15+ components, many
which contain multiple modules. The version numbers are all the same, and
a build cycle takes about four hours.
Late in a development cycle we run
On 18 January 2013 09:35, Joachim Durchholz j...@durchholz.org wrote:
Am 17.01.2013 23:17, schrieb Stephen Connolly:
First, when you are playing with install:install-file you will find that
you regularly need to blow away your local cache (which is the real name
of
the local repository
there.
Is there any current known issue on mojo-dev?
Thanks a lot.
2013/1/17 Baptiste MATHUS bmat...@batmat.net javascript:;
Nope, not yet. But I didn't submit much work today.
But that could push me to finally move my arse a bit more about it.
Thanks!
2013/1/17 Stephen Connolly stephen.alan.conno
Have you created a full account on xircles... I cannot find you in it
On Friday, 18 January 2013, Stephen Connolly wrote:
Very strange...
On Friday, 18 January 2013, Baptiste MATHUS wrote:
I tried to subscribe and write many times to mojo-dev without much luck.
This might be a PEBKAC
I would put such template source files in src/main/java-templates and knock
together a plugin that filters while copying the source to
target/generated-sources/template and then adds that as a source root in
one step.
I would suggest to knock sth together at mojo since a lot if people seem to
Have you got commit for mojo? if not I will start a vote... you've been
knocking around long enough!
On 17 January 2013 10:28, Baptiste MATHUS bmat...@batmat.net wrote:
2013/1/17 Stephen Connolly stephen.alan.conno...@gmail.com
src/main/java-template
Yop, I think you're right, I
On 17 January 2013 16:16, Joachim Durchholz j...@durchholz.org wrote:
Am 17.01.2013 10:08, schrieb Jörg Schaible:
Ah, I had seen that but thought it was inapplicable because I want to
deploy just to the local repo. But I guess I can tell it to deploy to
${settings.localRepository}, right?
On 17 January 2013 16:35, Ron Wheeler rwhee...@artifact-software.comwrote:
On 17/01/2013 11:16 AM, Joachim Durchholz wrote:
Am 17.01.2013 10:08, schrieb Jörg Schaible:
Ah, I had seen that but thought it was inapplicable because I want to
deploy just to the local repo. But I guess I can tell
That is really a default value not an expression
On 17 January 2013 17:01, Huang, Roger roghu...@paypal.com wrote:
Is there a way to specify an expression for the Mojo annotation @parameter
in Maven 3?
I have a Mojo, GenerateConfigMojo.java, with property
deliverableSettings of type
First, when you are playing with install:install-file you will find that
you regularly need to blow away your local cache (which is the real name of
the local repository)... that will kill you downloading everything again,
and because you had to do the install:install-file you have just lost all
ship-maven-plugin@mojo
On 11 January 2013 10:39, Rainer Völschow rvoel...@gmail.com wrote:
Hi Patrick,
one part of my question was, how can I pass the profiles to pom.xml
If what you want is to deploy a war with different servers (possibly with
different configurations), you could use
to modify the built artifact is a bad plan
(see
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html)
-Stephen
On 11 January 2013 10:49, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:
ship-maven-plugin@mojo
On 11 January 2013 10:39, Rainer Völschow rvoel
I haven't looked at your project but I have a suspicion as to what is going
on.
By default the javadoc.jar is not generated by a default build, so as a
result there is no javadoc.jar in the reactor and hence there is a search
of the local and remote repositories... but since these do not have the
Not an answer for you but an FYI: Maven trunk has moved to git
On 7 January 2013 13:47, Stadelmann Josef
josef.stadelm...@axa-winterthur.ch wrote:
Hi,
I did
openVMS
bash$ svn co trunk
bash$ mvn clean install
bash$
all the build steps indicates SUCCESS; lets do a cd and inspect
bash$
But I don't know why the maven build did not package this two files into
my tar.gz or zip file.
Josef
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesendet: Montag, 7. Januar 2013 14:56
An: Maven Users List
Betreff: Re
You can define a property in your Pom file and then set the configuration
with that property and then use the cli to override that property...
But the bigger question is *why* do you think you want to do this?
Most likely you don't and instead animal-sniffer is what you want...
Or perhaps there
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
Not just you. And the worst part is that Maven gets the blame for these
shitty plugins.
It's not Maven it's you (the shitty plugin authors).
On 31 December 2012 15:00, Anders Hammar and...@hammar.net wrote:
It might just be me, but I get tired of these crappy Maven plugins not
doing things
The biggest gain is to use a MRM and *ban* listing additional repositories
in the Pom.
On Friday, 28 December 2012, Marcos Mendez wrote:
Are there some general guidelines regarding build optimization?
For example, if you have multiple repos, for plugins, other artifacts,
release and
-roll it
On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
When artifacts get installed into the remote repository or local
repository cache, you do not have information about what profiles were
active when the artifact was built. as a result
21, 2012 at 3:32 PM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; wrote:
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Please don't do maven the way you are doing it
On Friday, 21 December 2012, Niranjan Rao wrote:
Greetings
I missing something?
Regards,
Niranjan
On 12/21/2012 12:32 PM, Stephen Connolly wrote:
http://developer-blog.**cloudbees.com/2012/11/maven-**
profiles-and-maven-way.htmlhttp://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Please don't do maven the way you
the line to the other servers.
Do you always release A and B together?
Yes. We tag (or branch) it all together. Then we manually update our
version numbers for each product in our code.
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.comjavascript:;
]
Sent
Since I mentioned deploying snapshots... I thought I would clarify my
thinking in that regard as a blog post!
http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html
On 22 December 2012 08:17, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Well those answers
I am not suggesting a *static* file. I am suggesting a dynamic file that
Jenkins populates and just one already existing cli parameter that works
with more versions of maven than anything we add now.
- Stephen
On Friday, 21 December 2012, Jesse Glick wrote:
On 12/20/2012 12:19 PM, cowwoc
Files that come and go also include the SCM tools installed on the build
slave by Jenkins. And Jenkins should put the paths it is injecting into
toolchains in the build log anyway, so I don't see your point about files
as being an argument winner.
Also a toolchains file allows the developer to
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Please don't do maven the way you are doing it
On Friday, 21 December 2012, Niranjan Rao wrote:
Greetings,
We have bunch of profiles and corresponding resource filtering which all
works great. One frequent problem
Do you always deploy A and B together?
Do you always release A and B together?
On Friday, 21 December 2012, Scott Klein wrote:
crap, that came out all horrible looking, let me try to fix that section
up ...
snip
Right now we have a number of individual Eclipse projects and we build
Well if you wanted to explore this, the way I would come at this is via
maven's toolchains api
Thus if the SCM tool had an entry for the HG executable in
~/.m2/toolchains.xml then that path would be used, otherwise whatever is
resolved from the path would get resolved.
Working on this will
-settings.xml / $HOME/.scm/git-settings.xml.
See http://maven.apache.org/scm/subversion.html and
http://maven.apache.org/scm/git.html
a simple $HOME/.scm/hg-settings.xml
with
hg-settings
hgPath/home/beer/wine/bin/hg/hgPath
/hg-settings
WDYT ?
2012/12/20 Stephen Connolly
Current work on Maven compiler plugin version 3.0 is adding support for an
incremental mode.
It is a tricky balance to cut, as if incremental mode is too aggressive,
you compile more than is strictly necessary... and if too lax, you compile
less than is required and people end up having to run
On 17 December 2012 03:28, Rick Mann rm...@latencyzero.com wrote:
On Dec 16, 2012, at 18:06 , Benson Margulies bimargul...@gmail.com
wrote:
You'll have to be a lot more specific. With the antrun plugin? With
something else?
I've posted a couple times with my specific query, but no
And I try to remove such bugs as and when I find them... but yes I agree
it's a pain... but people should be more aware that it is a hack and they
would be better served by fixing the root cause... not applying the
install hack
On 17 December 2012 12:26, Benson Margulies bimargul...@gmail.com
Reformatted and edited into something a bit more specific:
http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html
On 17 December 2012 12:45, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
And I try to remove such bugs as and when I find them... but yes I agree
it's a pain
On 17 December 2012 15:34, Laird Nelson ljnel...@gmail.com wrote:
On Mon, Dec 17, 2012 at 3:36 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Another issue is that people abuse the install hack far more often than
they should...
Hi; this is the first I've read anywhere
I would create a separate module that builds the test overlay war file and
leave the production artifact unmolested always
On Friday, 14 December 2012, Winsor, Daniel wrote:
Hi,
It appears we are using 2.0 of maven-war-plugin due to some incorrect
dependency graphs - at least that's what the
FYI: You should look for them in the list of reactor project first before
resorting to building a new model. Otherwise subtle effects to do with
order of installation into the maven repository can creep in
On 13 December 2012 11:53, Marcos Mendez mar...@jitisoft.com wrote:
Well. figured it
just that with a little elbow grease. i could also just parsed
the pom files myself for what i need...
On Dec 13, 2012, at 7:14, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
FYI: You should look for them in the list of reactor project first before
resorting to building a new
5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Can you please raise a JIRA for the NPE
On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com
wrote:
Someone please help me from navigating through the forest of no return,
that is Google, and tell me how
Actually the current behaviour is 1.5 is using Maven Compiler Plugin 2.5 or
newer (might be 2.4 but I'd need to check)
With Maven 3.1.0, the version of the Maven Compiler Plugin that you get if
you have not locked down plugin versions will be upped to a version with
this new default.
So if you
am not saying I will -1 upping the min JDK
required by Maven, just that compiler's default cannot be higher than the
minimum version required by Maven)
-Stephen
On 30 November 2012 15:53, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Actually the current behaviour is 1.5 is using
Point is, unless you are using java 1.3, until 2.5ish you have had the
source1.5/source and target1.5/target in your pom anyway.
So changing the default from 1.5 to 1.7 will not make life any harder for
you as you'll just be putting back in the source1.5/source and
target1.5/target (assuming you
That is a fair point. And I concur, that until core ups its minimum JRE
requirement, compiler shouldn't move past that...
Raises the question should core up to 1.6... I don't see a pressing need
yet...
Lambdas are not until 1.8, and we don't do the crazy generics stuff that,
for example, forced
You only get the new language features from after 1.5 if target 1.5, so
switching core to use the newer features would make core incompatible with
running on 1.5
On 29 November 2012 17:25, Ron Wheeler rwhee...@artifact-software.comwrote:
On 29/11/2012 12:01 PM, Curtis Rueden wrote:
Hi Ron,
is not that big a difference. 1.8's lambdas is a
different story though... but it will likely be a good while before we can
consider alienating all the pre 1.8 users
On 29 November 2012 18:14, Ron Wheeler rwhee...@artifact-software.comwrote:
On 29/11/2012 12:48 PM, Stephen Connolly wrote:
You only get
system.
On 11/27/12 5:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
The Mojo team is pleased to announce the release of the Versions
Maven Plugin, version 2.0
NOTE: This release requires Maven 2.2.1 or newer and consequently JRE 1.5
or newer.
NOTE: This is the *last
Up until m-c-p 2.5ish the default value for source was 1.3.
That was updated and newer versions of m-c-p use 1.5 as the default
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#source
Maven 3.1.0 will have m-c-p's default version pinned at least at 2.5, so
when that gets
Resource filtering!
On Wednesday, 28 November 2012, Steve Cohen wrote:
Is there a way in maven to echo some text provided via a property in
pom.xml into a text file at a given location?
--**--**-
To unsubscribe, e-mail:
and the new versions
plugin is attempting to be more strict in that area.
Thanks for all the assistance.
On 11/28/12 5:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Can you please raise a JIRA for the NPE
On 28 November 2012 08:04, Wheeler, Dennis dwhee...@cobaltgroup.com
I have a sneaky suspicion that you are doing some crazy stupid stuff in
your pom.
please provide the snippet which gave you the warning and what you think
the fix of that is based on the warning...
On 26 November 2012 13:44, Alberto Ivo alberto...@gmail.com wrote:
Hello Anders,
I've tried
:
You could also try looking at the effective-pom (help:effective-pom) and
search for ${artifactId} in that. It might be something you're inheriting.
But I'm also thinking something along Stephen's comment.
/Anders
On Mon, Nov 26, 2012 at 2:51 PM, Stephen Connolly
stephen.alan.conno
For a more build tool agnostic approach:
Have a test resource that gets the connection details filtered in
Then in your database tests, start each one with a Junit4 Assumption like
assumeThat(credentialsFromTestResource, is(not(nullValue()));
And now you can run all tests from your IDE too
There is support for generating source code from some form of template.
Usually requires a plugin for the template engine, or antrun and
build-helper:add-source
You would keep the template outside if src/main/java and then the
generated source goes to something like target/generated-source/...
Those ids correspond to the credentials defined in your settings.xml
If the servers are different but all will always belong to the same single
sign-on realm then perfectly fine to keep the same id
If they are different realms (even if you are being a bold boy using the
same password for every
I don't think the axis2 plugin had tool chains support yet. Somebody might
need to add it ;-)
On Wednesday, 14 November 2012, Claudio Query wrote:
Thanks for the suggestion.
Maybe I'm doing something wrong, but toolchains doesn't solve my issue
Also if I try to use jdk 1.6, it continues to
What SCM are you using. with SVN and IIRC with Git it currently works, but
that is likely a side-effect of the way those SCMs work.
On 5 November 2012 06:30, Thorsten Höger li...@hoegernet.de wrote:
Done! http://jira.codehaus.org/browse/MRELEASE-798
Regards,
Thorsten
Am 04.11.2012 20:37,
On 30 October 2012 10:14, Zak Mc Kracken zakmc...@yahoo.it wrote:
On 25/10/2012 02:47, Barrie Treloar wrote:
Maven will needless contact all five of your repositories looking for
artifacts that probably aren't even there.
This will require a tcp/ip connection for each one and when you have
Maven 3 requires that the artifact have originated from a valid repository,
so putting it in a profile will mean that it will only build with the
profile active. far better to just mandate a mirrorOf* to internal
nexus/artifactory/archiva server
On 22 October 2012 22:37, Laird Nelson
On 15 October 2012 22:24, Matthew Adams matt...@matthewadams.me wrote:
One of the questions in my original post was actually which pom
should you execute 'mvn release:prepare release:perform' on?. I'm
guessing, based on nothing else but intuition, that it's the parent
pom, not the root pom,
On 16 October 2012 07:45, christofer.d...@c-ware.de
christofer.d...@c-ware.de wrote:
As described in my other response. Simply keeping the versions in sync is
not an option for us due to the donwtime this would mean for our clients
and the load this would generate on the central servers.
Don't forget to change the artifactId to nar-maven-plugin or such as
maven-___-plugin is reserved for maven.apache.org owned plugins
On Tuesday, 9 October 2012, Curtis Rueden wrote:
Hi all,
Feel free to create it an invite the people :)
Done:
On 9 October 2012 21:12, Mark Donszelmann mark.donszelm...@cern.ch wrote:
Hi
On Oct 9, 2012, at 7:18 PM, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:
Don't forget to change the artifactId to nar-maven-plugin or such as
maven-___-plugin is reserved for maven.apache.org
felix will have to change
On 9 October 2012 23:11, Dan Tran dant...@gmail.com wrote:
felix uses maven-bundle-plugin. Not sure why plugin name is important
here.
-D
On Tue, Oct 9, 2012 at 2:38 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 9 October 2012 21:12, Mark
On 7 October 2012 16:36, Martin Eisengardt martin.eisenga...@gmail.comwrote:
OK. Thanks four your responses, Mark and Jason.
Lets sum up. We have the agreement of the authors to build up a new
working group.
I recently created a new organization at github:
https://github.com/maven-nar (just
On 8 October 2012 13:30, Martin Eisengardt martin.eisenga...@gmail.comwrote:
My employers (CloudBees) will give free jenkins instance to any Open
Source
project that asks for one.
Thanks for your support. Is your jenkins aware of native builds for win,
linux, sunosx, macosx and
thoughts but my 2.75 yr old son now is demanding to play
racing cars on my phone, so I need to hit send on this mail now ;-)
On Saturday, 29 September 2012, Jason van Zyl wrote:
On Sep 29, 2012, at 12:31 PM, Stephen Connolly
stephen.alan.conno...@gmail.com javascript:; wrote:
The issue I see
The issue I see is that there is a difference with ranges between build
time and run time.
In general at build time you want the lowest version in the range (assuming
the api is versions correctly) to ensure you are compatible with the
smallest set of api method signatures.
At run time you want
On 27 September 2012 14:41, Jesse Long j...@unknown.za.net wrote:
Dear Maven Community,
I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically regarding the defining compatible version ranges.
I am using Maven 3.0.4. I have a simple project that
. Sometimes we get caught out by what
Jesse outlined below.
On 27/09/2012 15:51, Stephen Connolly wrote:
On 27 September 2012 14:41, Jesse Long j...@unknown.za.net wrote:
Dear Maven Community,
I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically
range since
we cannot trust the producer of that artifact not to break their current
API in later versions unless they support semantic versioning.
On 27/09/2012 22:29, Stephen Connolly wrote:
when is that class applied?
each dependency would have its own comparator, as each dependency has
now), at least I would then
have a choice to replace it with an implementation I'm happier with.
Anyway it works for us as it is now, so I'm not going to lose any sleep
over it.
Cheers
On 27/09/2012 23:36, Stephen Connolly wrote:
Well that is a recipe for disaster. rules only make sense
like one day Eclipse learned the difference between JRE and the
general term Platform, Maven 4 has to learn this concept, too.
Maybe I should file a RFE for this?
Regards
Markus
-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Samstag, 22
601 - 700 of 2415 matches
Mail list logo
