Hi,
I have a requirement where I need to specify specific versions for a
set of (basic) plugins. Adding the versions to the pom isn't an option
because we need to set the plugin versions for a vast number of
_unrelated_ builds.
As I've found at [1], I've manually created a plugin-registry.xml file
A few minor observations (since you are soliciting them). I haven't run the
plugins or have any experience of not in the plugin domain, so I can't comment
on the goals or workflow.
1. I'm not sure of the benefit of putting the source on Bitbucket, versus under
Codehaus' Mojo project, the
I don't know about plugin-registry.xml, but you can distribute a
settings.xml for use with -gs that has an active-by-default profile
with a pluginManagement section that does the job.
On Mon, Jul 25, 2011 at 3:02 AM, Kasun Gajasinghe kasu...@gmail.com wrote:
Hi,
I have a requirement where I
--
-- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/
On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping topp...@codehaus.org wrote:
A few minor observations (since you are soliciting them). I haven't run
the plugins or have any experience of not in the plugin domain, so I
It's an interesting mojo, very promising.
What about extending it to EC2 instances manipulations ?
2011/7/25 Aldrin Leal ald...@leal.eng.br:
--
-- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/
On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping topp...@codehaus.org wrote:
On Jul 25, 2011, at 7:57 AM, Aldrin Leal wrote:
--
-- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/
On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping topp...@codehaus.org wrote:
A few minor observations (since you are soliciting them). I haven't run
the plugins or
On Mon, Jul 25, 2011 at 9:38 AM, Brian Topping topp...@codehaus.org wrote:
I didn't see your second link to github. Maybe I should have spent more
time reading your email, but there you go, feedback in the form of what
wasn't noticed.
Sure. I am also about to take a clone on brix-cms as
On 25 Jul 2011, at 17:13, Benson Margulies bimargul...@gmail.com
wrote:
I don't know about plugin-registry.xml, but you can distribute a
settings.xml for use with -gs that has an active-by-default profile
with a pluginManagement section that does the job.
Benson,
That would do the job
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
dbradic...@sonatype.comwrote:
Why not define the pluginDependency section in a parent pom, then each of
your projects uses this as a parent, and pulls in all the plugin dep
versions defined in it
Why not define the pluginDependency section in a parent pom, then each of
your projects uses this as a parent, and pulls in all the plugin dep
versions defined in it (or overrides in project pom if necessary). Seems
that would be simplest solution
Damian
On Mon, Jul 25, 2011 at 7:43 AM, Benson
Hello,
I use git together with gitflow(1) and would like to release projects the
gitflow way. Gitflow itself creates branches, a release tag and merges
changes back into other branches.
The maven-release-plugin performs similar things an other way. I tried to
use both together, but it works only
So i wanted to confirm that i only have ONE WAY TO write ONE WEB Project
which can bring up like this URL so in background my Project should use old
network location but HTTP location should follow the MAVEN standard.
that's the only way for me ??
Clearly we are all having trouble
In this scenario should it be expected that maven reactor will figure out
the correct build order and will follow that ( I mean it will make sure that
parents are built first. And similarly that dependencies are built first )
Generally yes the reactor will figure out the correct build order.
On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
dbradic...@sonatype.com wrote:
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
dbradic...@sonatype.comwrote:
Why not define the pluginDependency section in a parent pom, then each of
your
C:\maj\practices\maven\HotelDatabase\src\main\java\com\javaworld\hotels\model\Ho
telModel.java:[39,14] generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
C:\maj\practices\maven\HotelDatabase\src\main\java\com\javaworld\hotels\model\Ho
telModel.java:[42,22]
I have a maven war project and am using maven-cargo-plugin to deploy the war
to the container and also to start/stop the container for functional
testing. All works well on an internet-connected machine, but when I try to
execute my build on a disconnected machine, the cargo:deploy fails. I have
But why ? simply have a top level parent pom that is solely for defining
your plugin versions (and anything else that may cover all of your
projects), you don't need any project specific logic in there. The parent
doesn't need to list any of the children that use it (and act as an
aggregator),
Hi Wayne,
You understood me correctly. And our company is looking to use MAVEN
standards in future so i think the idea to create custom repository
structure will not be good for us.
We have to prove some projects with MAVEN first and make them easy going
with MAVEN. Then all projects will move
I still think that installing Nexus and using Maven and Nexus out of the
box for 1 project is the best way to start.
That will handle all of your needs for third party libraries and it will
only take a few minutes to upload the internal libraries that you
require to build the one project that
Sorry,
I know this is a question for apache or nexus lists (or both), but I
need some resolution so trying here as well.
I have a proxy repository to the apache ws-zones-proxy repository. It
stopped indexing correctly and now when I do a build I cannot download a
woden.jar artifact that
Hi Ron,
Yes I agree with Nexus, But the only concern in choosing Nexus is we have to
daily copy our latest JAR files from Existing location to New location for
Even 1 Project. As so many dependency on those Jar files and which are daily
updating. So we have to daily Update the new Nexus location
So I downloaded Nexus 1.9.2, watched the video, read the user manual on
starting Nexus, entered
C:\Program Files
(Open)\Sonatype\nexus-oss-webapp-1.9.2-bundle\nexus-oss-webapp-1.9.2bin\jsw\windows-x86-64\nexus
start
and got back
FATAL | wrapper | Unable to open configuration file.
This is more a m2eclipse plugin issue and less maven but if any has an answer
or can point me in the right direction, I'd appreciate it.
I have eclipse indigo (v3.7) for mac and it came preinstalled with m2eclipse
(v1.0.0.20110607-2117). I believe both are one of the most recent builds.
Anyways,
I'd run it from a directory that does not contain spaces or other non
alphanumeric characters. Yours has two spaces, one of each different
parenthesis, and a in it.
Nexus is a very robust and easy to use installation that gets a lot of
attention. You are not supposed to waste time on
This is a bug, it is sure.
Probably due to spaces in your path (programs don't love them in general).
Arnaud
On Mon, Jul 25, 2011 at 9:06 PM, Eric Kolotyluk eric.koloty...@gmail.comwrote:
So I downloaded Nexus 1.9.2, watched the video, read the user manual on
starting Nexus, entered
OK, so it is a bug, the correct way to start it is to go to the actual
directory and run
nexus.bat
without any parameters. Things seems to start up, but when I go to
http://localhost:8081 I get
HTTP ERROR: 404
Problem accessing /. Reason:
NOT_FOUND
Powered by Jetty://
I do have an open
Try http://localhost:8081/nexus.
On Jul 25, 2011, at 3:30 PM, Eric Kolotyluk wrote:
OK, so it is a bug, the correct way to start it is to go to the actual
directory and run
nexus.bat
without any parameters. Things seems to start up, but when I go to
http://localhost:8081 I get
I think now this better fits the Nexus mailing list. Thank you.
On Mon, Jul 25, 2011 at 3:31 PM, Brian Topping topp...@codehaus.org wrote:
Try http://localhost:8081/nexus.
On Jul 25, 2011, at 3:30 PM, Eric Kolotyluk wrote:
OK, so it is a bug, the correct way to start it is to go to the
Greetings,
On Mon, Jul 25, 2011 at 3:14 PM, kanesee kane...@gmail.com wrote:
This is more a m2eclipse plugin issue and less maven but if any has an answer
or can point me in the right direction, I'd appreciate it.
http://eclipse.org/m2e/
http://m2eclipse.sonatype.org/project-information.html
Yes I agree with Nexus, But the only concern in choosing Nexus is we have to
daily copy our latest JAR files from Existing location to New location for
Even 1 Project. As so many dependency on those Jar files and which are daily
updating. So we have to daily Update the new Nexus location too.
First impressions are very important - this one was pretty bad. How much
time am I supposed to waste now trying to figure out how to actually start
Nexus?
(snip)
These are all GREAT questions and comments for the Nexus Users list.
Feel free to continue this discussion there. This is the Maven
Hi,
I use maven3/tycho and maven-dependency-plugin to copy dependencies to my
local lib. But cannot exclude org.eclipse.*.jar. Is there a way to exclude
them?
I tried excludeGroupIdsorg.eclipse.core/excludeGroupIds to exclude
org.eclipse.core.jobs.jar but it does not work. It still copies
the book is most probably not uptodate. M2E had to follow Eclipse
guidelines on main menu content when being accepted into indigo
release train and all/most of the menu items are gone now.
Milos
On Mon, Jul 25, 2011 at 9:14 PM, kanesee kane...@gmail.com wrote:
This is more a m2eclipse plugin
I tried excludeGroupIdsorg.eclipse.core/excludeGroupIds to exclude
org.eclipse.core.jobs.jar but it does not work. It still copies
org.eclipse.core.jobs.jar to my local lib folder.
Are you sure org.eclipse.core.jobs.jar has the groupId
org.eclipse.core? Check the pom before making any
On 25/07/2011 3:47 PM, Wayne Fay wrote:
Yes I agree with Nexus, But the only concern in choosing Nexus is we have to
daily copy our latest JAR files from Existing location to New location for
Even 1 Project. As so many dependency on those Jar files and which are daily
updating. So we have to
Yes you are absolutely right. Yes currently it's hard for debugging as we
don't know which version of JAR is breaking the Environment.
that's the reason we want to move with Maven we can know our artifact build
version and believe me it's very hard to change these things when you have
more then
We have two sets of (database and logging) settings, for development and
productions builds. We're using dev and prod profiles to choose the
appropriate settings for each environment.
Do you think using a classifier to differentiate artifacts built for
development and production is hacky, is
We're using gitflow/maven quite nicely, I use for my release plugin:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
You will likely get better help on the cargo maven plugin asking on the
Cargo mailing list [1].
/Anders
[1] http://cargo.codehaus.org/Mailing+Lists
On Mon, Jul 25, 2011 at 18:15, John Singleton jhsin...@gmail.com wrote:
I have a maven war project and am using maven-cargo-plugin to deploy the
It's bad. Your builds should be environment neutral. Try to get the
configuration outside of the binary.
Also, please search the archive on this topic as it has been discussed
several times already this year.
/Anders
On Mon, Jul 25, 2011 at 22:13, Daniel Serodio (lists)
Nexus not being able to download the index has no impact on it being able to
proxy an artifact, So that's not the issue.
You should probably move this thread to the Nexus list as clearly the repo
still exists as you can reach it through a browser.
/Anders
On Mon, Jul 25, 2011 at 19:58, Meeusen,
Am 25.07.2011 22:13, schrieb Daniel Serodio (lists):
Do you think using a classifier to differentiate artifacts built for
development and production is hacky, is is this an appropriate
solution?
Use the same *artifacts* for all stages and allow for *configuring* the
relevant properties of
Do you think using a classifier to differentiate artifacts built for
development and production is hacky, is is this an appropriate solution?
IMHO this is OK and not hacky so long as there are ONLY
configuration/settings files in the jars and not actual binaries that
have configuration wrapped
http://blog.artifact-software.com/tech/?p=58
Part of the solution.
Ron
On 25/07/2011 4:25 PM, Ansgar Konermann wrote:
Am 25.07.2011 22:13, schrieb Daniel Serodio (lists):
Do you think using a classifier to differentiate artifacts built for
development and production is hacky, is is this an
On 25/07/2011 4:27 PM, Wayne Fay wrote:
Do you think using a classifier to differentiate artifacts built for
development and production is hacky, is is this an appropriate solution?
IMHO this is OK and not hacky so long as there are ONLY
configuration/settings files in the jars and not actual
What I *think* Wayne is talking about is deploying the environment
configurations wrapped in jars and deploy them to the repo (you would deploy
a separate jar for each environment). And then during the actual copy to the
runtime environment pick the appropriate one (from the repo).
It does work if
On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
dbradic...@sonatype.com wrote:
But why ? simply have a top level parent pom that is solely for defining
your plugin versions (and anything else that may cover all of your
projects), you don't need any project specific logic in there. The
This is exactly what I'm talking about, and its not an uncommon
pattern of use and not (IMO) an anti-pattern or something to be
explicitly avoided, so long as how you then USE those config jars is
thought through. I think it makes some sense in some scenarios but
then I also have to question the
As a general principle, the design of maven is trending toward locking
down the versions of plugins for a build. Otherwise, you can't grab an
old version of the source from a tag and depend on building it.
Therefore, the idea of a separate 'control panel' for plugin versions
is not popular.
Thanks - that did the trick.
I'll stop bothering everyone on the maven list now :-)
Cheers, Eric
On 2011-07-25 12:31 PM, Brian Topping wrote:
Try http://localhost:8081/nexus.
On Jul 25, 2011, at 3:30 PM, Eric Kolotyluk wrote:
OK, so it is a bug, the correct way to start it is to go to the
I'm still not seeing the problem, certainly a specific release of a parent
pom would be static, but if you need to update versions, you update the pom
and release a new version, then update your projects to use it as necessary.
It is a simple workflow, and leaves a single place where all versions
On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies bimargul...@gmail.com wrote:
As a general principle, the design of maven is trending toward locking
down the versions of plugins for a build. Otherwise, you can't grab an
old version of the source from a tag and depend on building it.
On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich
dbradic...@sonatype.com wrote:
I'm still not seeing the problem, certainly a specific release of a parent
pom would be static, but if you need to update versions, you update the pom
and release a new version, then update your projects to use it
53 matches
Mail list logo
