Eclipse can't open a pom.xml file from the command line? For Intellij-idea
on Mac, Windows or Linux, I'd just do `idea pom.xml`
- Paul
On Sat, Feb 3, 2024 at 11:44 AM Matthias Bünger
wrote:
> Hey all,
> in this mail I want to share my experiences / thouhgts I had on my way
> from the decision
OK, ignore me, you're talking about the other way.
On Thu, Aug 24, 2023 at 1:27 PM Paul Hammant wrote:
> A classic pom.xml at root in a single repo, then multiple levels of child
> directory each with its own pom.xml (and its own src/main/java &
> src.test/java) ?
>
> Br
A classic pom.xml at root in a single repo, then multiple levels of child
directory each with its own pom.xml (and its own src/main/java &
src.test/java) ?
Branching model would be trunk based development (and branch for release),
possibly as short-lived feature branches in the GitHub
I wrote much of
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=118163392#content/view/118163392
20 years back, and still stand by the basic message.
Maven is a build tool though, and aims and reproducibility. Minimal output
should be the default (console and log files). If
Corporations that do anti-virus content filtering of incoming GETs, have
occasionally seen corrupt jars in ~/.m2 and their shared
Nexus/Artifactory. In that case there was text content for the jar (insead
of a zip) and if you looked at it, you saw a HTML page talking of the A-V
transgression but
Apache used to operate Gump for this purpose, back on the days of Ant and
Maven 1.x.
https://github.com/hboutemy/mcmm-yaml could gain some additional
post-publication meta info :)
Google for "embedding Maven". Articles like
https://techblog.bozho.net/embedding-maven/ talk about that.
Sounds great. Quick check - this is a fork of Maven somehow? Or additional
plugins that are configurable into standard Maven?
I too published something on quicker Maven builds that's lower tech -
https://paulhammant.com/2021/01/28/dagging-on-maven
- Paul
log
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-devel
>
> JSR 330 has a TCK that defines a lot. A system that purports to facilitate
> injection into contained components (plugins or lesser) doesn’t have to
> implement all facets of that TCK but could do so out of the box by just
> using (say) guice or dagger in a class loader tree implementation.
CDI came after JSR330 I think. I was on the JSR330 experts group. I could
be wrong there.
Back history of dependency injection - it was an antidote to classic GoF
service-locator being used everywhere in Javaland. When we co-created
PicoContainer we were careful to avoid Singleton as a term or
https://github.com/asciidoctor/jekyll-asciidoc-quickstart .. find “GitHub
pages” in page.
My blog used to be in textile - overnight GHP dropped support so I had to
batch convert hundreds to markdown. That was years back. I might have
preferred asciidoc, and if it is supported that’s great, but I
I don't think so - it's tied to SHA1 presently and would require updates to
multiple plugins. I mean for your own DAV-style repository you could ALSO
publish SHA256s, but there's no verification cycle as deps are pulled into
a build client-side that'd use them.
Relates to Trunk-Based Development (I maintain
https://trunkbaseddevelopment.com) . Some of my clients do "branch for
release". Every cherry pick from trunk to the release branch (bug fix)
would wake up Jenkins. By default that'd do a full build and then artifacts
get pushed into artifactory/nexus
Thanks Tamás
After building that all, Is there a trick to instantiating mvnDebug using
those snapshots ?
- Paul
I'm still clicking around trying to find the piece of code I'm interested
in. I've found
MessageDigest(string).getInstance(“SHA-1”).update(various), but not
succinctly how it links to the upload/publish process.
I've already made the change I want for GraknLab's
"bazel-distribution" (Python)
Thanks for that. Me 15 years ago would have know the answer as bells are
ringing now :)
I can't find where the HTTP-PUT logic is for deployment of Maven artifacts
to remote repos.
I was looking in 'maven-deploy-plugin' and 'maven-artifact-transfer' but
could not see the logic that pushes artifacts up to maven-central (or any
other properties-specified repo).
I'm wanting to play
Shade has option exclude rules if you wanted to slim down that side of it,
and still stick with Jackson.
Shading itself should alter the should or shouldn't aspect of
library/package linkage within a app/lib/service/plugin/solution. You're
guided by imports in Java-land - Apache license stuff
https://github.com/mojohaus/buildnumber-maven-plugin has been worked on
*since* Codehaus closed up. Ask these people -
https://github.com/mojohaus/buildnumber-maven-plugin/commits/master - what
their intentions are.
Selenium co-creator here (albeit v1),
WebElement is pubic API and not impl-detail. If you're making a library
for downstream *testing* teams to use, then selenium-java jumps from
test-scope to prod-scope of course and is now a transitive dep. Many
build/test tools makers are in the same place
I'm interested in your need for this. Like, why do you need this?
On Thu, Jan 23, 2020 at 7:17 AM Scott Wilson wrote:
> *Hi Robert and devs*
>
>
> *I have been using maven for a few years and I LOVE it!*
>
>
> *I have a feature request.*
>
>
> *(1) When adding a dependency to pom.xml the
> We have tens of plugins, most of them are rarely updated and released
... is the key problem you're trying to solve right?
Team to actively process issues and PRs and push releases minor releases
efficiently is the real wish, right?
Without breaking backwards compatibility, it could be a choice for the Pom.
Sure that’s an addition, but it it not like the format can never change.
It’s an excellent idea.
On Thu, Nov 28, 2019 at 5:28 PM Robert Scholte wrote:
> As mentioned by Elliotte this won't fit in the current pom model
Great suggestion
On Wed, Nov 27, 2019 at 10:37 PM diku gabriell
wrote:
> Hello,
>
> My name is Gabriel Dicu.I am currently working with apache maven and I’d
> like to make a suggestion about improving maven dependency structure.In my
> opinion, dependencies should be organized better, because
Integration test choices include the excellent Spock as mentioned. I've
used it and it's very solid. Two more choices include:
Another choice is Cuppa - https://github.com/cuppa-framework/cuppa
I've used this too, and it's great - no right-click-run-this-one in
Intellij though. I wish it had more
Oops. Blog entry linking to video of 16s build -
https://paulhammant.com/2017/02/05/a-16-second-java-webapp-build-including-webdriver-tests/
Here's an interesting co-incidence. A chg I donated to Google's Cloud bits
and pieces -
https://github.com/GoogleCloudPlatform/google-cloud-datastore/pull/205/files
*required
and received* a CLA.
@elharo just marked it as not needed, which is quite correct as this lib
has been succeeded by
and the
> carrying of a personal imprint
> - original expression is feasible for AIs (according to author)
>
> The author lost me at the reasoning for "personal imprint".
>
> Martijn
>
> On Tue, Oct 29, 2019 at 11:18 AM Paul Hammant wrote:
> >
> > Summar
Summary ?
Pretty sure that small changes that could not be done any other way are not
subject to copyright claims.
s/1.199/1.200/g
^ Being an example.
On Sat, Oct 19, 2019 at 7:51 PM Enrico Olivelli wrote:
> I see value in it.
> But from a legal point of viewthere is no human who sends the PR, so
Java 8 rapidly starts adding lambdas that make the
> code more obfuscated for no good reason and soon introduces hard
> dependencies on Java 8, intentionally or otherwise. At a bare minimum,
> a CI environment that runs Java 7 is required.
>
> On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
Would jdk 8 for maven itself and a target of 7 for the compiler (etc) for
maven-using projects be ok?
On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold
wrote:
> Strong -1 on Java 8 as the minimum version. Google Cloud Platform has
> lots of products and customers that still require Java 7.
Hunter wrote:
What if that timestamp was based upon the scm's last commit timestamp
> instead of the time of the build?
>
Folks: remember that Subversion works differently to Git. With subversion
there's no hash, just an integer that goes up constantly for everything in
the larger repo. Your
Nice, thanks :)
Class
maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder is
where "Child module of does not exist" causes the build
to cease. I'd like to make that optional for myself for huge-monorepo and
sparse-checkout-coolness reasons. Is that the best place to make Maven
more
There's shades of https://en.wikipedia.org/wiki/XY_problem to what you
posting. I, for one, an interested in what your trying to make after you've
solved this problem :)
Make sure there's a slide on speedily processing pull-requests -
https://github.com/apache/maven/pulls - ;-) :-P
On Mon, Mar 18, 2019 at 12:03 PM Karl Heinz Marbaise
wrote:
> Hi to all,
>
> I would like to please you if you have simple task to do it would be
> great if you could create an
Does 'central' need to be immutable though? Feels like an arbitrary policy
to me. Or should there be workflows to remove items from there, and replace
with a 302? While that could be to repos elswhere, they could also be to
HTML pages with mvn.exe handling that and communicating that clearly in
It is probably up to Oracle (not Apache) as to what is uploaded into Maven
Central - https://mvnrepository.com/search?q=ojdbc7
It could be that they have decided to not upload artifacts - "Last Release
on Oct 30, 2017" - anymore.
Yeah, maybe that makes sense.
On Thu, Feb 14, 2019 at 1:45 PM Mykola Nikishov wrote:
> Paul Hammant writes:
>
> > mvn clean install -DskipTests
> -Dmaven.repo.local=/usr/local/var/MAVEN_CI_REPOSITORY
>
> This would compile and test-compile for the first time...
&g
The depth first DAG traversal of Maven modules in a build is a great and
under appreciated thing, but sometimes I wish for a different way of
working. Particularly for CI, I'd want to compile everything first, *then*
run tests. Two DAG traversals, if you like. This is possible, like so:
mvn clean
Obligatory, "Trunk-Based Development (with short-lived feature branches if
you like) is best" -
https://trunkbaseddevelopment.com/short-lived-feature-branches/ - *shout
out*.
- Paul (majority author of the above site).
Related to Incremental - idempotent builds would be good.
Having been exposed to Google's Blaze (now Bazel in OSSland) and directed
graph build system science (as opposed to recursive build systems) there's
a great efficiency from skipping parts of a build that don't need to be
done.
Also
nes.
> The only three problems I see with this implementation right now are:-
> obfuscated libs;- signed libs;- libs that use reflections to load classes
> (like spring).
> Does anybody know if this should be possible?
>
> Thanks,Bogdan Neacsu
>
--
Paul Hammant DevOps <https://devops.paul
Can you yourself try another dissimilar machine?
ai64n.html
> [2] The Maven output claims 6 seconds, but that doesn't include the
> time it took for the build to start.
>
> --
> Mark Raynsford | http://www.io7m.com
>
>
--
Paul Hammant DevOps <https://devops.paulhammant.com> Let me give your
enterprise a step by step plan to get out of the hell of crazy branching
models (ClearCase maybe?) and into the world of high-throughput CD on
DevOps foundations.
OS/X == OS X (former OS name) == macOS (current OS name) ?
10 == 10.10.x ?
s dependency checking
> and issue a warning, say a special HTTP response code or a header?
>
> Then, Maven would raise the warning in the console log, like "this
> component is known to have CVE-XYZ! consider upgrading"
>
> What do you think?
>
--
Paul Hammant DevOps <
>
>
>
> >
> > *3. More pluggable dependency resolver:*
> >
>
> I am willing to let this be optional scope for now. May be yanked if too
> risky or not ready in time
>
>
>
I don't see how you can even make it optional without a pom specified way
of saying "not maven central, this way/place instead"
structure.
Like here - https://github.com/paul-hammant/xstream-jar/releases (and
associated blog entry -
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/)
In particular I need to rework the jar as it is pulled into the local
~/.m2/repository cache - there's a root directory
>
> This should be possible by providing WorkspaceReader implementation -
> @Component( role = WorkspaceReader.class, hint = "ide" )
>
> Note that Maven tries resolution from workspace *before* repositories -
> workspace reader has priority lower than reactor, but higher than remote
> repos known
://trunkbaseddevelopment.com/branch-for-release/ has a Contribute to
this page
<https://github.com/paul-hammant/tbd/edit/master/content/branch-for-release/index.md>
link
that you can harmless click right now to see where that ends up :)
On Fri, Jul 21, 2017 at 12:28 PM, Anton Tanasenko <atg.sleepl...@
My bad - sorry.
On Thu, Jul 6, 2017 at 7:34 AM, Michael Osipov <micha...@apache.org> wrote:
> Am 2017-07-06 um 13:16 schrieb Paul Hammant:
>
>> For something that's 500MB in size (random binary data) I'm experiencing
>> commits taking
>> 10x longer than a straight
For something that's 500MB in size (random binary data) I'm experiencing
commits taking
10x longer than a straight copy to the drive the Svn repo is on.
Both timings are on the same Ubuntu 17.04 machine, with the boot drive
being the starting position of the 512MB file and a USB3 mounted 4TB
PM, Paul Hammant <p...@hammant.org> wrote:
> OK, I tried something new.
>
> *Goal*: all the plugins in one Git repo (less CI jobs to set up - just
> one recursive multi-module maven build).
> *Constraint*: Plugins must be independently releasable.
>
> *Test:* Take tw
needs two and a parent pom in master).
*Repository*: https://github.com/paul-hammant/ph_testplugins
Of the two modules checked in, maven-changes-plugin is the one I attempted
to release to my com/paulhammant/ group on 'Central. The workflow for the
release of that single module is here
https
is still on my todo-list.
> >
> > Robert
> >
> >
> > On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant <p...@hammant.org>
> wrote:
> >
> > Easy to fix. Have a profile 'platformOnly' in the root module (I'm not
> >> sure if 'BOM'
Easy to fix. Have a profile 'platformOnly' in the root module (I'm not
sure if 'BOM' should mean anything to me) that includes only 'platform' as
a child module.
mvn release:prepare -PplatformOnly # etc
Later when you're ready to do the demo store release, use another (from
root):
mvn
n, Jun 19, 2017 at 12:42 PM, Paul Hammant <p...@hammant.org> wrote:
> > Back from Github's suggestions team: "Currently, we don't have the
> ability
> > to group repos beyond the organization level, but I'll definitely
> consider
> > this a feature request."
&
Back from Github's suggestions team: "Currently, we don't have the ability
to group repos beyond the organization level, but I'll definitely consider
this a feature request."
- Paul
On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant <p...@hammant.org> wrote:
> I met Chris Wa
al ;-)
>
> On Sun 18 Jun 2017 at 23:10, Paul Hammant <p...@hammant.org> wrote:
>
> > They're always very polite for things that I ask for, but I can't claim
> to
> > have suggested anything that got implemented. I've a better hit-rate with
> > JetBrains and their IDEs
las)
>
> On 18 June 2017 at 10:12, Paul Hammant <p...@hammant.org> wrote:
>
> > Good thought. We could ask about a timeline.
> >
> > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
Good thought. We could ask about a timeline.
On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> They are now adding user grouping... I wonder how long before repo grouping
> too
>
> On Sun 18 Jun 2017 at 17:12, Paul Hammant <p.
t; [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration
>
> [2] https://cwiki.apache.org/confluence/display/MAVEN/Git
> +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos
>
> Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit :
> >
In order to be able to build a composite 'trunk' for all components of
maven (that are org.apache.*) can we move the remaining things left in
Subversion to Git, and mirror them to Github?
`git submodule` (etc) would be how we'd recreate a developer experience
that felt like a single trunk that
order to be able to reprieve
> artifacts from a new service, not the Dependency plug-in.
>
> Regards,
> Plamen Totev
>
> On Jun 4, 2017 14:23, "Paul Hammant" <p...@hammant.org> wrote:
>
> > So I have 27 releases of XStream unzipped and pushed to
> &g
So I have 27 releases of XStream unzipped and pushed to
https://github.com/paul-hammant/mc-xs-classes
(8.4M of Jars is now 2.4M of bare .git repo)
All the jars are still available - here -
https://github.com/paul-hammant/mc-xs-classes/releases
Perfect except:
1. .zip suffix instead of .jar
I mention it :)
- Paul
On Fri, Jun 2, 2017 at 6:47 AM, Paul Hammant <p...@hammant.org> wrote:
> The tongue-stickty-outy thing was more about the fact that Maven would be
> much better off shifting *all* of is documentation into something where
> every page has an edit-this-page link. E
, 2017 at 3:03 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Thu 1 Jun 2017 at 18:21, Paul Hammant <p...@hammant.org> wrote:
>
> > So the only one that worked as the -D arg to the maven invocation. I
> > checked the 10K jar into source control
https://maven.apache.org/examples/maven-3-lifecycle-extensions.html needs
an update methinks. If only Apache had a wiki :-P
- Paul
On Thu, Jun 1, 2017 at 9:22 AM, Paul Hammant <p...@hammant.org> wrote:
> OK, thanks.
>
> I'll kill the /build/extensions element of the pom,
t;core extension" [1], which can be
> configured in .mvn/extensions.xml in your project source tree and are
> loaded very early during the build, before Maven core plexus container
> is created.
>
> [1] http://takari.io/book/91-maven-classloading.html
>
> --
> Regards,
&g
This page:
https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
My problem: I have an extension that works just fine
in ${maven.home}/lib/ext/ isn't activated when I do the all the things
mentioned in the page.
So my extension was copied from one the Takari EventSpy plugins
, 2017 at 6:11 AM, Paul Hammant <p...@hammant.org> wrote:
> You know, I think it would be cool if there were file systems that would
> implement a form of a 'link' as part of a content-based-storage mechanism
> like Git itself. Meaning if I ran the above git-clone/jar command twice in
You know, I think it would be cool if there were file systems that would
implement a form of a 'link' as part of a content-based-storage mechanism
like Git itself. Meaning if I ran the above git-clone/jar command twice in
two different directories it would only store the result once (assuming
) from the blog entry:
git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3
cd mc-xs-classes
rm -rf .git
jar cvfM ../xstream-1.4.3.jar .
cd ..
rm -rf mc-xs-classes
That might be faster for Java and the widely used JGit if it can be done in
memory. It took 3 secs for me,
Hervé,
Maven Monitor was a Maven 2 artifact [1]
> It was dropped in Maven 3 "as an artifact": code was moved to maven-core
> during the Great Refactoring (TM) [2]
>
>
Thanks - it's a total red herring to chase that component then.
> Then you'll see that EventMonitor has been deprecated, in
And as I'm comfortable advocating for a few Git-centric alternates, GitHub
could be a hosting platform for jars of classes too. I think I've
established that it is efficient for storing binary classes.
The https://github.com/paul-hammant/mc-xs-classes/releases page on the
mc-xs-classes I did
h the registry model that I think just doesnt really work in the real
> world.
>
> manfred
>
> Paul Hammant wrote on 2017-05-17 13:39:
>
> > Actually I'm proposing a predictable structure on 'central :
> >
> > g...@central.maven.org:
> > maven2/<gro
Actually I'm proposing a predictable structure on 'central :
g...@central.maven.org:
maven2/
On Wed, May 17, 2017 at 3:41 PM, Aldrin Leal <ald...@leal.eng.br> wrote:
> thats my point: the golang approach does no magic at all. It simply stores
> the source code and bases it on a convention. Just the files, and thats it.
>
> --
> -- Aldrin Leal, <ald...@leal.eng.br>
ons.
:)
- Paul
On Wed, May 17, 2017 at 3:29 PM, Robert Scholte <rfscho...@apache.org>
wrote:
>
> On Wed, 17 May 2017 20:41:02 +0200, Paul Hammant <p...@hammant.org> wrote:
>
>> I would agree that it has the potential to be a new repository
>> implementation, Robert.
>&
n) - https://github.com/paul-hammant/mc-xs-all
- Paul
On Wed, May 17, 2017 at 2:54 PM, Aldrin Leal <ald...@leal.eng.br> wrote:
> I understand the approach is basically general, but maven artifacts are way
> more than binary code (there's source and javadoc). I also understand its
&
ldrin Leal, <ald...@leal.eng.br> / http://about.me/aldrinleal
>
> On Wed, May 17, 2017 at 1:35 PM, Paul Hammant <p...@hammant.org> wrote:
>
> > Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files
> added
> > to Git. Git makes 70% saving on bytes u
Hervé,
on classes branch, splitting the jar into individual .class has IMHO a big
> drawback: we loose original jar and its signature
>
Agree. Git doesn't care about timestamps for classes in jars. Java doesn't
either, but SHA1 (etc) of the jar does.
Thus - the next iteration will reproduce
://github.com/paul-hammant/mc-xs-all I have the sources,
classes, and javadoc as separate branches in one repo.
2. For https://github.com/paul-hammant/mc-xs-classes and
https://github.com/paul-hammant/mc-xs-javadocs and
https://github.com/paul-hammant/mc-xs-sources I have three Git repos per
group
Aldrin - https://github.com/paul-hammant/mc-xs-all - no large files added
to Git. Git makes 70% saving on bytes used ('bare' mode).
On Wed, May 17, 2017 at 11:10 AM, Aldrin Leal <ald...@leal.eng.br> wrote:
> Just a friendly reminder that git is not optimized for la
.
I'm trying to work out what a phase listener would look like, and thought
that the closed API to something that participates in the phase traversal
is MavenMonitor. Advice please?
- Paul
On Fri, May 12, 2017 at 6:01 AM, Paul Hammant <p...@hammant.org> wrote:
> I''m looking to mak
ncurrency is even harder.
> >
> >
> > Definitely, the idea is funny, but I don't see how this could go very far
> > than
> > this funny idea (in addition to the complexity for implementing this
> > format in
> > tooling)
> >
> > Regards,
> >
> >
One more repo:
https://github.com/paul-hammant/mc-xs-all/
One branch for each of classes, javadoc, sources, and poms
15 javadoc original versions: 24.1M
16 sources original versions: 4.9M
27 classes original versions: 8.4M
Afterwards git work the bare .git folder is: 8.4M
*77.5% saving
chatty that http://
is true. That's probably more CPU on the server side. It is definitely more
time. See here ...
Git takes 1s to do:
git clone https://github.com/paul-hammant/mc-xs-classes --depth 1 --branch
1.4.3 --bare
Wget takes 0.5s to do:
wget http://central.maven.org/maven2/com/thoughtworks
Article updated to eliminate misunderstandings and talk about a different
index for 'maven central' too.
- ph
On Sat, May 13, 2017 at 3:04 PM, Paul Hammant <p...@hammant.org> wrote:
> I was discussing this of the list today, and it may interest people on dev@
>
> https://paulhamm
I was discussing this of the list today, and it may interest people on dev@
https://paulhammant.com/2017/05/13/maven-central-as-multiple-git-repos/
"Maven Central as multiple Git repositories"
Enjoy,
- Paul
I''m looking to make a build radiator. Something like this -
https://www.stevefenton.co.uk/wp-content/uploads/2015/07/cruiser.jpg
I don't want to scrape logs to detect maven phase changes, and
corresponding pass/fail, I want to use a plugin. I think that plugin
is Maven-monitor
Online
r Maven on SDKMAN, and I sincerely wish to give them
> what they ask for. Whether the community is willing to lend a hand is
> entirely up to the *committers* of this project.
>
> On Sun, 16 Apr 2017 at 00:12 Paul Hammant <p...@hammant.org> wrote:
>
> > Marco,
> >
>
Marco,
You could sell your idea better, I think. You have "Most of the big
projects want to do this" as one of the stronger arguments in favor, which
isn't enough. For 20 years, Lean/Agilistas have focussed on "what is the
problem you're trying to solve?". And that is the question, I personally*
Prior conversation -
https://www.mail-archive.com/search?q=Vermeulen=dev%40maven.apache.org
On Sat, Apr 15, 2017 at 6:56 PM, Marco Vermeulen
wrote:
> Hi Maven folks,
>
> Some time ago I asked the Maven dev community whether they would be willing
> to publish their
>
>
>> I don't see any activity either, so my idea is to replace XStream, see
> MWAR-397[1]
>
Just for the record, Jörg is working through the Java9 issues for XStream
presently - https://github.com/x-stream/xstream/commits/master
- Paul
http://maven.apache.org/plugins/maven-idea-plugin/
It is marked as "retired", yet it is still available for resolution through
regular dependency declarations. Bug reports are referred to JIRA on
Codehaus (RIP).
Can we get https://github.com/apache/maven-idea-plugin 1) setup, 2) the GH
issue
1 - 100 of 114 matches
Mail list logo