On Tue, Jul 26, 2011 at 3:58 AM, Damian Bradicich
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 as necessary.
> It i
On Tue, Jul 26, 2011 at 3:33 AM, Benson Margulies 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.
>
> Therefore, the idea of a
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
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 a
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. Global
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 pr
On Mon, Jul 25, 2011 at 9:46 PM, Damian Bradicich
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 parent
> doesn't need to l
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 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
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 a
> 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 wrapp
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
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,
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) <
daniel.lis...@xxx.com.b
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 wrote:
> I have a maven war project and am using maven-cargo-plugin to deploy the
> war
> to the con
We're using gitflow/maven quite nicely, I use for my release plugin:
org.apache.maven.plugins
maven-release-plugin
2.1
deploy
false
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"
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 10
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 dai
> I tried org.eclipse.core 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 assumptions. It may
be org.eclipse an
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 wrote:
> This is more a m2eclipse plugin issue and less mave
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 org.eclipse.core to exclude
org.eclipse.core.jobs.jar but it does not work. It still copies
org.eclipse.core.jobs.jar to my local
> 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 Mav
> 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 to
Greetings,
On Mon, Jul 25, 2011 at 3:14 PM, kanesee 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
-Jesse
--
Ther
I think now this better fits the Nexus mailing list. Thank you.
On Mon, Jul 25, 2011 at 3: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 actual
>> directory
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
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 m
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 wrote:
> So I downloaded Nexus 1.9.2, watched the video, read the user manual on
> starting Nexus, entered
>
> C:\Program Files (Open)\Sona
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 ins
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,
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.2>bin\jsw\windows-x86-64\nexus
start
and got back
FATAL | wrapper | Unable to open configuration file. C:\Pro
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 t
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
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 yo
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 wi
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), th
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
c
> 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:[4
On Mon, Jul 25, 2011 at 5:34 PM, Damian Bradicich
wrote:
> err...pluginManagement section even ;)
>
> Damian
>
> On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
> wrote:
>
>> Why not define the pluginDependency section in a parent pom, then each of
>> your projects uses this as a parent, and pul
> 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
> 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 unders
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
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 M
err...pluginManagement section even ;)
Damian
On Mon, Jul 25, 2011 at 8:02 AM, Damian Bradicich
wrote:
> 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 proj
On 25 Jul 2011, at 17:13, Benson Margulies
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 though that's not exactl
On Mon, Jul 25, 2011 at 9:38 AM, Brian Topping 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 well
I don't see a
On Jul 25, 2011, at 7:57 AM, Aldrin Leal wrote:
> --
> -- Aldrin Leal, / http://www.leal.eng.br/mnemetica/
>
>
> On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping wrote:
>
>> A few minor observations (since you are soliciting them). I haven't run
>> the plugins or have any experience of not in
It's an interesting mojo, very promising.
What about extending it to EC2 instances manipulations ?
2011/7/25 Aldrin Leal :
> --
> -- Aldrin Leal, / http://www.leal.eng.br/mnemetica/
>
>
> On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping wrote:
>
>> A few minor observations (since you are soliciti
--
-- Aldrin Leal, / http://www.leal.eng.br/mnemetica/
On Mon, Jul 25, 2011 at 8:15 AM, Brian Topping 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 can't
> comment on the goals or workflo
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 wrote:
> Hi,
> I have a requirement where I need to specify spe
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 latte
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
53 matches
Mail list logo
