uot;java-commons-cli")
> (version some-version)
> (source this-thing-raises-an-error)
> ...))
>
> In other words, you won't be able to actually build language-tool until
> you insert proper sources in all the source fields – which Julien fears
>
to actually build language-tool until
you insert proper sources in all the source fields – which Julien fears
maven, being a binary distribution system first and foremost, won't
deliver on its own.
Cheers
Julien Lepiller writes:
>
> There's no importer and an importer would be a bit limited as it won't be
> able to get proper sources most of tge tine, though importing the dependency
> graph would be useful already. Would you like to give it a try? :)
>
Can you elaborate on this? How can I impor
Le 25 octobre 2022 04:10:51 GMT+02:00, Declan Tsien a
écrit :
>
>I believe LanguageTool[1] is a Java project using Maven as it's building
>tool.
>
>Lazy me. Instead of digging the mailing list and source code which would
>cost too much time and may not work out
I believe LanguageTool[1] is a Java project using Maven as it's building
tool.
Lazy me. Instead of digging the mailing list and source code which would
cost too much time and may not work out. I packaged the binary
distribution (jar files) using =copy-build-system= which I am trying to
g
Hi Julien,
there seems to be a licensing issue with packaging the S3 transporter
for Clojure so I think I won't continue working on this.
If I do and need help I ping you.
Thanks for your help!
Roman
Julien Lepiller writes:
> You could try updating maven resolver, but that means
>> I would like to enable the S3 transporter for the Clojure package. For
>> this I need version 1.8.2 of the Maven Resolver packages. Right now we
>> have version 1.6.3 packaged in Guix.
>
> AFAIK, you don't need to. IIUC, the patch series at
> <https://issues.g
You could try updating maven resolver, but that means you will also have to
rebuild all its dependents and make sure they don't break.
Maven stuff are a bit fragile under Guix because we can't build them as
intended. There's a chicken-and-egg problem with maven, its depend
On 03-09-2022 17:38, Roman Scherer wrote:
Hello Guix,
I would like to enable the S3 transporter for the Clojure package. For
this I need version 1.8.2 of the Maven Resolver packages. Right now we
have version 1.6.3 packaged in Guix.
AFAIK, you don't need to. IIUC, the patch seri
Hello Guix,
I would like to enable the S3 transporter for the Clojure package. For
this I need version 1.8.2 of the Maven Resolver packages. Right now we
have version 1.6.3 packaged in Guix.
Should I update the existing packages to 1.8.2 or create new package
variants with a 1.8 prefix for this
nd this?
None of my previous e-mail's attempts worked, but using Guix Inferiors
this morning to make "guix" itself the inferior (rather than the maven
package), my pacakge then actually built. Adopting the example given
in the manual, I was able to create a profile out of the below
builds
fine with the maven-build-system. So I suggest you to pull to the
latest master commit and enjoy :)
Don't hesitate to get back if you still have issues on master, I'll be
happy to help!
Le Tue, 8 Feb 2022 15:27:14 +, Phil Beadling
a écrit :
> Hi Guixers,
>
> First let
Hi Guixers,
First let me say I'm a Maven novice, so it's possible I'm doing something
dumb on the Maven side of things.
I'm unable to make a bare-bones Maven project build in Guix.
This looks to be a problem with mismatched dependencies in Guix around
java-commons-co
On Sun, 20 Sep 2020 07:35:44 -0400
Julien Lepiller wrote:
> >Does someone have plans to add real-world packages that make use of
> >the maven-build-system? Next, an automated importer with
> >dependency-resolution would be nice :-)
>
> The issue with the importer is t
Le 20 septembre 2020 04:55:55 GMT-04:00, "Björn Höfling"
a écrit :
>Hi Julien,
>Hi Guix,
>
>thanks for adding the maven-build-system to Guix! This week I found the
>time to look over it and tested it. It works great!
>
>First I head a problem with symlinks whe
Hi Julien,
Hi Guix,
thanks for adding the maven-build-system to Guix! This week I found the
time to look over it and tested it. It works great!
First I head a problem with symlinks when I tried out your example from
your git:
(define-public maven-test
+ (let ((commit
On Sun, 5 Apr 2020 at 06:20, Pierre Neidhardt wrote:
> Hi Julien,
> thanks for this great summary, looking forward to it!
Same here, Julien :-)
> By the way, Leandro was planning to work on Clojars, so having a
> functioning maven build system might be helpful to that task.
Than
Hi Julien,
thanks for this great summary, looking forward to it!
By the way, Leandro was planning to work on Clojars, so having a
functioning maven build system might be helpful to that task.
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
On Sat, Apr 04, 2020 at 05:52:37PM +0200, Julien Lepiller wrote:
> Before I send a patch series (~200 patches if i count well),
It will be more convenient for reviewers if you pushed a
wip-maven-build-system branch to Savannah.
On Sat, 4 Apr 2020, Julien Lepiller wrote:
Hi Guix!
great news! I have successfully built a hello world package with a
fully bootstrapped maven-build-system! This email will summarize a bit
what I did and how I got there. For the impatient, my work is
currently at https://framagit.org
Hi Guix!
great news! I have successfully built a hello world package with a
fully bootstrapped maven-build-system! This email will summarize a bit
what I did and how I got there. For the impatient, my work is
currently at https://framagit.org/tyreunom/maven-build-channel. You can
build maven
ow about the profile hooks. Nevertheless:
I want to emphasis that maven does *not* support some kind of "system
repository", as I explained in my original post. Even if you mimic a
"system repository", this will always *copy* the artifacts to
$HOME/.m2/repository. Debian uses so
Hartmut Goebel writes:
>> and have a phase to build a union of these with symlinks. Hopefully,
>> maven will follow the symlinks.
>
> The drawback of this approach is: This only works within the
> build-system. Since within a normal environment or profile, there will
>
Hartmut Goebel writes:
> * Debian stores the files in a system repository structured like
> above, see [9]. (Thought this seem not to be done for all packages,
> |e.g.|||[6] and [7] do not include ||these maven-repo files.)
> * Debian provides a script "mvn-debia
Hi,
Am 31.01.19 um 18:06 schrieb Julien Lepiller:
Here are my 2cent:
> We found that we need more plugins to be able to build maven projects, and
> that requires some metadata in the jar file. This metadata is generated by
> maven-plugin-tools-generators, and maybe we can write a
Le 31 janvier 2019 11:00:42 GMT+01:00, Hartmut Goebel
a écrit :
>H Julien,
>
>as promised I've spend some time on a maven build system (as always
>when
>regarding maven it was much more time than expected). I did not yet
>create a build-system but want to share my insight
H Julien,
as promised I've spend some time on a maven build system (as always when
regarding maven it was much more time than expected). I did not yet
create a build-system but want to share my insights so we can decide how
to proceed further. If I'm wrong on some points, please fe
Am 24.04.2017 um 03:20 schrieb Hilco Wijbenga:
> First, if it's about trust ("am I really running a stock,
> unmanipulated Maven") then there are the checksums and signatures on
> the download page which exist for exactly that purpose.
While signatures are very useful in
2017-04-24 14:58 GMT+02:00 Hartmut Goebel :
>
> Yes, this is one of the issues bugging me to quite often.
I'm not sure I understand. This doesn't happen with the guix checkout that
I usually build
>
> Within the
> environment you'll also need to run:
>
> export SSL_CERT_DIR="$GUIX_ENVIRONMENT/e
Am 24.04.2017 um 14:41 schrieb Catonano:
> I tried to build your branch just out of curiosity and the configure
> of Guix fails because
>
> configure: error: The Guile bindings of GnuTLS are missing; please
> install them.
>
> I'm running this inside a
>
> guix environment guix
>
> so I assume all
ava
> … org.apache.maven.cli.MavenCli -X").
>
> > 3. Do you have a WIP branch and instructions on how to reproduce this?
>
> You can find the branch "WIP-maven" at
> https://gitlab.com/htgoebel/guix.git. To reproduce simply run
>
> git clone https://gitlab.com
the component is build from exactly the known source and not manipulated.
Sure, that makes sense ... up to a point.
First, if it's about trust ("am I really running a stock,
unmanipulated Maven") then there are the checksums and signatures on
the download page which exist for exact
And this means, that neither adding JARs from Maven Central to the store
nor putting the maven tar-ball into the store are admissible options for
Guix. I know other distributions do, like NixOS, but Guix will not.
Sadly maven does not support building from source. Even the maven
"source"
Hi Hartmut,
On 21 April 2017 at 03:46, Hartmut Goebel wrote:
> I'm seeking for help from some skilled Java developer. I nearly finished
> bootstrapping maven: I made it to start up, but now fails with this
> error message:
>
> org.apache.maven.InternalErrorExcep
anch and instructions on how to reproduce this?
You can find the branch "WIP-maven" at
https://gitlab.com/htgoebel/guix.git. To reproduce simply run
git clone https://gitlab.com/htgoebel/guix.git
cd guix
git checkout WIP-maven
./pre-inst-env guix build maven-for-bootstrap
> 2. So
On Fri, 21 Apr 2017 12:46:40 +0200
Hartmut Goebel wrote:
> Hi,
>
> I'm seeking for help from some skilled Java developer. I nearly
> finished bootstrapping maven: I made it to start up, but now fails
> with this error message:
>
> org.apache.maven.InternalErro
Hi,
I'm seeking for help from some skilled Java developer. I nearly finished
bootstrapping maven: I made it to start up, but now fails with this
error message:
org.apache.maven.InternalErrorException: Internal error:
com.google.inject.ProvisionException: Unable to provision, see the
foll
Hi,
Ludo suggested me to ask on the mailing-list:
I'm seeking for some funding for working on Guix. Project-based this
could be bringing maven into guix.
Working on Guix is a lot of fun, but I'm a freelancer, so I need to make
my living somehow. Currently I'm spending too mu
our new
> approach? I'm asking because Ricardo wanted to work on them two weeks
> ago:
These patches are most probably outdated and will be overhauled.
My current strategy is to build "bootstrap" versions for each of these
packages and then build the "real" ones usin
Björn Höfling writes:
> Hi Hartmut,
>
> great to hear these news on Java/mvn development! Thanks for taking the
> time.
>
> You posted half a year ago a series of patches that are not yet
> integrated into Guix:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-09/threads.html#00774
>
> Are
ge.java program, with a few
alterations:
- we're a bit more careful about handling /* in end-of-line comments
and Strings
- I wrote an Ant task called MungeTask that supports munging an entire
fileset"
I also found a Git rebository for a Maven plugin for Munge:
https://github.com/sona
Hello,
TL;DR: some progress on packaging maven; still a lot todo; need help
from Java-developers.
1) Some progress on packaging maven
I spent quite some on packaging maven again. This time I took a
different approach which looks promising; maven comes with a list of
transitive dependencies and
s
and checksums :-)
So here are my scratches from my work on packaging some java packages
and maven. Good Luck!
Notes for a "junits" ant task: outputting the reports into some
"${build.home}/test-reports"
tches and some "report" to
> the mailinglist later this week.
I'm interested in your report and want to go on with Maven on GuixSD.
> I gave up on packaging further Java packages. It's a abottomless pit
> of recursive dependencies.
Java people care too little about
Am 06.09.2016 um 00:15 schrieb Björn Höfling:
> I'm interested in which version of maven do you start to create? Which
> version(s) of the dependencies/plugins are you rebuilding?
I started building the current version of maven, since the others are
outdated and I did not want
Hi Björn,
> I'm interested in which version of maven do you start to create? Which
> version(s) of the dependencies/plugins are you rebuilding?
I decided to start with the latest and build as many dependencies as
possible without Maven. I briefly considered packaging an older vers
Hi Hartmut and Ricardo,
On Thu, 1 Sep 2016 14:03:10 +0200
Ricardo Wurmus wrote:
>
> Hartmut Goebel writes:
>
> > is anyone working on this? (I'm lacking knowledge to help with maven
> > or gradle, but could help with commons.)
>
> We are still a long way o
Hartmut Goebel writes:
> Am 02.09.2016 um 13:48 schrieb Ricardo Wurmus:
>
>
> > I found all of these need intervention for building, as there is no
>> "install" target (maybe I missed something). Echo of the packages
>> behaves a bit different (e.g. different directory names), while
Am 02.09.2016 um 13:48 schrieb Ricardo Wurmus:
>> > I found all of these need intervention for building, as there is no
>> > "install" target (maybe I missed something). Echo of the packages
>> > behaves a bit different (e.g. different directory names), while
>> > sharing some common patterns. I'll
Hartmut Goebel writes:
> Meantime I managed to build commons-io, commons-cli, commons-lang and
> commons-codec.
Cool!
> I found all of these need intervention for building, as there is no
> "install" target (maybe I missed something). Echo of the packages
> behaves a bit different (e.g. differ
llow-other-keys)
(zero? (apply system* `("ant" "javadoc" ,@make-flags)
(replace 'install ;install-jars)
(lambda* (#:key outputs #:allow-other-keys)
(let ((share (string-append (assoc-ref outputs "out")
lt in the
> prettiest packages.
>
> Curiously maven requires commons-io, and commons-io can officially be
> build using maven. That's crude!
That’s a common problem, unfortunately (Maven itself needs Maven, for
example). The “ant-build-system” can generate a simple “build.xml” f
Hallo,
> apache-commons
>
> These might have unpackaged dependencies of their own. If you took over
> “apache-commons” that would be very helpful. You should be able to use
> the “ant-build-system” to get started, even if it doesn’t result in the
> prettiest packages
Hartmut Goebel writes:
> is anyone working on this? (I'm lacking knowledge to help with maven
> or gradle, but could help with commons.)
We are still a long way off before get to a working maven build system.
I have a few more Java packages sitting here, but it’s not much.
We fi
Hi,
is anyone working on this? (I'm lacking knowledge to help with maven or
gradle, but could help with commons.)
--
Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software
Develo
Danny Milosavljevic writes:
> I also tried to package the Arduino GUI - but it has lots of Apache
> Commons dependencies and those use the Maven repo system.
>
> Has anyone already packaged Apache Commons libraries?
I have not, but the few Java packages I contributed were added
Hi,
I also tried to package the Arduino GUI - but it has lots of Apache Commons
dependencies and those use the Maven repo system.
Has anyone already packaged Apache Commons libraries?
Hello!
Ricardo Wurmus skribis:
> Roel and I discussed this off-list already and we thought it would be a
> good idea to bring this discussion to the list. (This email recycles
> sentences both Roel and I wrote in our off-list discussion; mistakes are
> all mine.)
I’m afraid I don’t have anythi
On 02/29/2016 11:14 AM, Ricardo Wurmus wrote:
Since not every application uses Maven (or even the same version of
Maven), and I cannot yet be certain that the directory layout remains
the same across different versions of Maven, I think it would be best to
generate this dynamically rather than
have a
maven-build-system. By default Maven downloads binary artifacts from a
remote Maven repository. The required binary artifacts are listed in
“pom.xml” files and identified by a combination of “groupId”,
“artifactId”, and “version”[1].
According to the documentation[2] it is possible to
60 matches
Mail list logo
