Hi,
Even with a single organization having config outside the project is a
right pain. Instead of it's maven, you know what to do, you have
some weird site specific ritual to perform, and this creates friction.
FWIW, in general, I agree 100%. One of the beautiful things about Maven is
that
On 28 May 2015, at 16:58, Manfred Moser manf...@mosabuam.com wrote:
I think having a global config for this would be good. Personally I think
having .m2/extensions.xml would be a good way to do it.
Can you describe the use case?
It seems this only makes sense if you only ever do work for one
Use cases I can think of (there are probably more)
- use concurrent safe local repo access for all builds on a CI server without
having to modify all projects
- enabling extension for multi thread logging or any other feature like
coloring or so across all projects I work on locally
- allow
Can you give each developer their own snapshot repo (perhaps hosted on
the virtual machine that is running their tests) that their virtual
machine uses for snapshots?
Releases would come from the central release repo.
This would be easy to do with Nexus and probably easy with other Maven
Hi all,
I would like to be able to centralize our company's branding of Javadoc
and cannot figure out how to do that with the Javadoc plugin.
All projects in our company inherit from the same POM, known as our company pom.
So far, so good.
We've managed to centralize the use of our Javadoc
because if you want global extensions, there is a mechanism that exists for a
long time: put jar files in lib/ext
the new .mvn/extensions.xml feature is really about permitting non-global
extensions, to ease per-project tests before making the extensions global (and
if the extension is a
So just to be clear you don't actually have to add the artifact itself but a
declaration of the artifact and it will be downloaded. We really only first
thought about project specific extensions, making sure the mechanism worked
with the type of bootstrapping required, proper classloader
Jason,
My 2 cents... The idea of organization-wide settings is not a new one. I
would be hard-pressed to find an organization that is not using a maven
repository internally and the distributed .m2/settings.xml seems like the
right place for this. Everyone in the organization has to have the
Hello team,
Actually, I'm building a pom parent that all applications under the enitty
where I'm working will have to implement.
The idea is to specify all the dependencies and plugins inside the pom
parent with the version using the dependencyManagement and
pluginManagement, and at the
The downside here is that what you might have configured locally, personally,
may conflict with what a project might have setup.
At the project level it's safe, organizationally it can be if curated but a
personal setup working with something not explicitly configured for a specific
project is
True ... with great power comes
But to lighten that we could by default say that project based extensions
override global ones.
Realistically I think we just have to use it all more and get more practical
experience with extensions to see where we might want to head next.
Manfred
Jason
I think having a global config for this would be good. Personally I think
having .m2/extensions.xml would be a good way to do it.
You could introduce e.g. Igor's logging here, add the Takari concurrent local
repo access and so on in a declarative fashion and truly customize your Maven
The Maven site plugin can use any content written in e.g. asciidoc, markdown
and so on to create a site and you can use a skin to change the look and feel.
Maven itself and most plugins do that.
If that is not what you are looking for you could e.g. use the Maven site
plugin for the docs and
Sounds like you are thinking about something similar to what we use.
Works very well and makes life very easy for developers.
http://blog.artifact-software.com/tech/?p=121
Ron
On 28/05/2015 10:30 AM, Mehdi Hayani wrote:
Hello team,
Actually, I'm building a pom parent that all applications
We often have a virtual machine for each developer, where they can deploy
code from their own branch (foo) for testing, in a continuous manner. These
virtual machines use a configuration management tool to pull binaries from
a remote drive, built by a continuous integration build server. The code
I think some of the more complex use cases we've worked through: like the Ruby
DSL for JRuby and Aether connectors. Both those work and Igor is working
through one of the tricky ones now which is logging. I've seen a few extensions
in the wild too so hopefully there isn't going to be much we
16 matches
Mail list logo
