|
Maven status: still bad
|
#
¿
Dec 12, 2019 20:20
|
|
|
|
| # ¿ May 10, 2024 05:52 |
|
|
Also rip if your company uses bamboo, it’s not bad apart from maven but the world will punish you forever for using it and not Jenkins
|
|
#
¿
Dec 12, 2019 20:22
|
|
|
Share Bear posted:a lot of shims that force stuff not in java to build
|
|
#
¿
Dec 12, 2019 20:37
|
|
|
Shaggar posted:maven rules and is the only good build system.
|
|
#
¿
Dec 12, 2019 20:38
|
|
|
CRIP EATIN BREAD posted:i had to write a bamboo plugin that let me define a static file to drop into the build directory of a project right before it builds. for whatever reason the suggested mechanism in bamboo is to write a bash script that generates the file.
|
|
#
¿
Dec 12, 2019 22:58
|
|
|
dads friend steve posted:alright so if not maven what am I supposed to use to build my trash java apps?
|
|
#
¿
Dec 21, 2019 20:09
|
|
|
dads friend steve posted:oh my god no
|
|
#
¿
Dec 21, 2019 20:24
|
|
|
gradle provides modules that can be configured similar to maven using far more efficient and readable syntax (lol @ hand-edited xml) however it is magical thinking to suppose that these pre-existing modules will always cover the emergent needs of any organization and for those cases gradle lets you go procedural as needed, reusing parts of those modules at the level where they are indeed reusable maven's architecture is that any emergent need has to be captured immediately as a plugin, before you can proceed at all. you don't get to express it procedurally at first so that you can feel out the requirements and what the configuration points are. this pushes you to create "reusable" plugins that are not in fact reusable and should be done over, but we know that necessary do-overs have a way of not ever happening (though in observed practice people will just hack in an antrun goal rather than create a plugin, while crossing their fingers that it doesn't conflict with maven's "opinions" about goal sequencing, because bro there's a friggin deadline)
|
|
#
¿
Dec 21, 2019 21:08
|
|
|
I know that pain
|
|
#
¿
Dec 21, 2019 22:14
|
|
|
More like circumvention over configuration
|
|
#
¿
Dec 21, 2019 22:35
|
|
|
If there are never emergent needs then why does Maven even provide a plugin api and why have plugins been created for it, huh genius
|
|
#
¿
Dec 21, 2019 22:39
|
|
|
i have never seen any other build tool that demanded more developer attention and babysitting than maven. even the build system developed for windows NT (a boatload of cmd scripts driven by nmake) managed to be more intuitive
|
|
#
¿
Dec 22, 2019 02:07
|
|
|
even if i had it it wouldn't be mine to post, and anyway we both know that your response would be "why are you doing the dumb things" while ignoring the answer I have always given, that the management mandated the use of maven while also imposing requirements (esp. variant builds) that conflict with maven's "opinions"
|
|
#
¿
Jan 11, 2020 21:22
|
|
|
it is though, because the purpose of a build system is to do what it's told and maven can't be told what to do
|
|
#
¿
Jan 11, 2020 21:26
|
|
|
one particluar requirment for variant builds, was that entry points to an artifact had to be renamed on a per-customer basis as an additional obscurity measure on top of the underlying security solution. the customers wanted it, so they got it! the way this worked — put in place before I arrived, I think by our very "innovative" co-founder — was - each customer's renaming config was recorded in an XML file - the build server ran maven package to build the code from source (no tests, customers don't pay for tests you dummy) - at the end of that stage, maven executed antrun to call out to an external build.xml - the build.xml read in the renaming config and used xmltask to generate a custom target for the renaming and then executed it. then it zipped the artifacts into a distribution - next the build server ran maven again with um, the install goal? the package goal again with a different profile? i don't remember - that goal, whatever it was, executed a gmaven task, which is maven executing a groovy script - the groovy script did some other last-minute stuff that i don't remember but ant wasn't able to do, then it repeatedly ran maven deploy commands to push specific artifacts to the repository with different types and classifiers this was not the only variant-build requirement but it probably is the most entertaining story and the general theme of the whole process is having to graft things that are programmable onto maven because directly programming maven according to your business requirements is like pulling teeth e: oh i forgot to mention, at one point I added another big step and another subordinate tool to this process, while leaving all the others in place because deadlines, then fortunately i was able to beg my lead for a week to dive in and remove the xmltask stage Gazpacho fucked around with this message at 22:00 on Jan 11, 2020 |
|
#
¿
Jan 11, 2020 21:56
|
|
|
|
| # ¿ May 10, 2024 05:52 |
|
|
what maven does well: pulling libraries, fixing the top-level directory layout and especially a single top-level build output directory. this last one is such a small thing but it makes builds immensely more repeatable and despite this people at PrevCo would still fight against it
|
|
#
¿
Jan 11, 2020 23:08
|
|