(Disclaimer: I only know Gradle from outside. I never used it more than 2
minutes, but I read some things about and saw a prez at our JUG.)
Gradle has a very different approach: where Maven values sometimes not much
flexibility at first sight (to improve build genericity, as already said),
Gradle
This is not how you should do things IMHO. You should make your common
jar generic enough so it can be used on the client side and the sever
side without adjustment (changing the jar). Any client side specific
code should go into the client module (producing the client jar) which
has a dependency
You will have to make your own assessment but most new projects I see in my
customer base are moving over to gradle. It offers the same convention over
configuration advantages of Maven but with some flexibility if you need it,
plus a whole swag of benefits that are gradle specific. The dependency
Gradle allows to hack something much quicker. In Maven you would need to write
a plugin.
Otoh I've seen a Gradle project which went from great to barely maintainable in
almost under a year.
Just let a few juniors touch the build and you are doomed pretty quickly.
The approach of gradle is not
hi,
I have a project developed in java using eclipse. This project is using a
set of jars. We are trying to execute now this project using maven.
I have configured the pom file for every jar dependecy smth like:
dependency
groupIdorg.eclipse.uml2/groupId
Using Maven without your own Repo is a horrible waste of time.
Get one of the repos (We use Nexus) installed and configured and you
life will get a lot simpler.
Ron
On 11/09/2012 5:09 AM, MeJ wrote:
hi,
I have a project developed in java using eclipse. This project is using a
set of jars. We
With great power comes great responsibility (Starwars? Kung-fu panda?
not sure anymore :)
Spiderman. Come on now... You get points for maven knowledge but minus points
for missing the Spiderman reference. Three cheers for Stan Lee ;-).
On Sep 11, 2012, at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote:
Using Maven without your own Repo is a horrible waste of time.
Get one of the repos (We use Nexus) installed and configured and you life
will get a lot simpler.
Really? It's that bad? Why doesn't it say this in
Oki, I confess... hang me now
line on the left, only one cross each person
;)
LieGrue,
stru
- Original Message -
From: Thiessen, Todd (Todd) tthies...@avaya.com
To: Maven Users List users@maven.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Tuesday, September 11, 2012
On 11/09/2012 8:36 AM, Brian Topping wrote:
On Sep 11, 2012, at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote:
Using Maven without your own Repo is a horrible waste of time.
Get one of the repos (We use Nexus) installed and configured and you life will
get a lot simpler.
Really?
Please tell me how we can add a task in POM.xml file to zip the source code
separately while build the application. I want both .war file and .zip files
independent of each other.
Thank you in advance.
-
Madhu
--
View this message in context:
You can use either the Maven source plugin [1] or the more generic Maven
Assembly Plugin [2] if you want more control of what goes into your zip.
-Jim
[1] http://maven.apache.org/plugins/maven-source-plugin/
[2] http://maven.apache.org/plugins/maven-assembly-plugin/
-Original
Hi,
Please tell me how we can add a task in POM.xml file to zip the source
code
separately while build the application. I want both .war file and .zip
files
independent of each other.
https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html
I noticed a comment in
http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not
using the release plugin because it checks in POMs after updating versions,
which isn't suited to a continuous delivery pipeline. Is the release plugin
intended to be run manually, and not
On 11 Sep 2012, at 6:02 PM, KARR, DAVID wrote:
I noticed a comment in
http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not
using the release plugin because it checks in POMs after updating versions,
which isn't suited to a continuous delivery pipeline. Is the
On Sep 11, 2012, at 7:02 PM, KARR, DAVID dk0...@att.com wrote:
I noticed a comment in
http://www.dzone.com/links/r/continuous_delivery_using_maven_3.html about not
using the release plugin because it checks in POMs after updating versions,
which isn't suited to a continuous delivery
My recommendation is to keep your release builds manual or cron based. You can
add a release:prepare -DdryRun=true -B to your CI if you want to make sure
that a future release build will work properly. The main issue with using
source change detection in a CI job and running the release
Continuous Delivery challenges that belief.
I am not convinced either actually. Particular for very large enterprise
builds where final artifacts are in the order of gigs in size. Imagine a
project that large with dozen of developers committing to the code base many
times a day and releasing
I noticed a comment in ... about not using the release plugin because it
checks in POMs after updating versions, which isn't suited to a continuous
delivery pipeline. Is the release plugin intended to be run manually, and not
part of an automated build?
The plugin can be used in an automated
Hi everyone,
Just let a few juniors touch the build and you are doomed pretty quickly.
I agree, and would generalize this statement to any build system I've ever
designed or worked with: shell scripts, Makefiles, Ant, Maven... it doesn't
matter. A build is a very finicky thing, especially for
On Sep 11, 2012, at 8:22 PM, Curtis Rueden ctrue...@wisc.edu wrote:
I'm not advocating that junior developers not be allowed to touch the
build—otherwise how will they learn?—but I strongly recommend code review
of any changes a junior developer makes to a build system.
Kind of roaming away
On 11 Sep 2012, at 7:22 PM, Curtis Rueden wrote:
Just let a few juniors touch the build and you are doomed pretty quickly.
I agree, and would generalize this statement to any build system I've ever
designed or worked with: shell scripts, Makefiles, Ant, Maven... it doesn't
matter. A build
can somebody give me the sample code...
-
Madhu
--
View this message in context:
http://maven.40175.n5.nabble.com/How-to-zip-the-source-code-separately-using-Maven-tp5721257p5721311.html
Sent from the Maven - Users mailing list archive at Nabble.com.
I'd just like to add that although Maven encourages convention over
configuration etc etc, it will by no means by itself ensure that you
get good build scripts (poms aren't scripts, but I think you know
what I mean). I've seen so many weird/strange/bad/fascinating
solutions incorporated into
On 11/09/2012 2:51 PM, Anders Hammar wrote:
I'd just like to add that although Maven encourages convention over
configuration etc etc, it will by no means by itself ensure that you
get good build scripts (poms aren't scripts, but I think you know
what I mean). I've seen so many
If they bring their ideas here, they usually get the kind of advice that
leads to good practices.
Well, the problem is that they don't go here. They just happily go on
trying to invent the wheel (but a square one).
/Anders
They also have to frame their questions at the goal level rather than
Every time that 'continuous delivery' shows up on this mailing list,
we end up with 10,000 lines of opinionated email about this
extraordinarily controversial topic.
I respectfully plead with all of you to use this mailing list for
practical, answerable, questions about the behavior of Maven, and
I don't think it's useful to debate build tools and their builders or
tools on this list.
On Tue, Sep 11, 2012 at 3:26 PM, Anders Hammar and...@hammar.net wrote:
If they bring their ideas here, they usually get the kind of advice that
leads to good practices.
Well, the problem is that they
On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote:
I don't think it's useful to debate build tools and their builders or
tools on this list.
I believe it is very useful. Many new users to maven don't fully understand the
problem maven tries to solve, and a discussion like this one will
What will happen to maven if we moderate discussions touching continuous
delivery aggressively?
Those who do want to use CD, which tools will they use? Where can they
learn how to use maven for CD?
How can maven developers learn how maven could evolve to facilitate maven
usage in CD setups?
I find also such discussion interesting
it is always good to know what is existing arround and if some inputs may
drive to improve Maven itself.
The fact to know also why Maven is here is an important thing to better us
it.
This is especially what we did with Nicolas De loof in our French book few
Am 11.09.2012 22:59 schrieb Arnaud Héritier aherit...@gmail.com:
I find also such discussion interesting
it is always good to know what is existing arround and if some inputs may
drive to improve Maven itself.
The fact to know also why Maven is here is an important thing to better us
it.
On Tue, Sep 11, 2012 at 4:33 PM, Graham Leggett minf...@sharp.fm wrote:
On 11 Sep 2012, at 10:14 PM, Benson Margulies wrote:
I don't think it's useful to debate build tools and their builders or
tools on this list.
I believe it is very useful. Many new users to maven don't fully understand
I have used maven for CD on some projects... But I find CD to be less
useful than a simple release often approach.
The key take home of CD for me is that you always should be able to release
the master branch. That no long lived branches should exist is secondary.
Actually pushing releases every
34 matches
Mail list logo
