To get the snapshots I'd use the maven dependecy plugin (e.g.
dependency:copy), if maven is an option at all.
Cheers,
Roger
2013/11/20 Laird Nelson
> Have a look at this:
>
> http://stackoverflow.com/questions/7911620/using-the-nexus-rest-api-to-get-latest-artifact-version-for-given-groupi
Have a look at this:
http://stackoverflow.com/questions/7911620/using-the-nexus-rest-api-to-get-latest-artifact-version-for-given-groupid-artfic
Basically unless you want the pain of digging into yet another undocumented
overly verbose alpha API to do this programmatically, use the (documented,
st
> Someone I work with needs to build an automated solution to get the latest
> version of a snapshot jar from our nexus server. They've tried the simplistic
> "wget/curl" solution, but that requires hardcoding the verbose snapshot jar
> url.
> What are cleaner ways to do this?
...
> Is this somet
Someone I work with needs to build an automated solution to get the latest
version of a snapshot jar from our nexus server. They've tried the simplistic
"wget/curl" solution, but that requires hardcoding the verbose snapshot jar
url. What are cleaner ways to do this?
This could be automated e
On 19 November 2013 08:14, laredotornado-3 wrote:
> Hi,
>
> I'm using Maven 3.0.3 and trying to use the Maven release plugin to do a
> release of a child module, which inherits from a parent pom. The parent has
> been released but does not include the child in its module list, and won't
> be able
I have a project that has multiple dependencies for example a.*:*:* and
b.*:*:*
now in one build profile I am using assembly plugin to assemble a fat jar
for that profile I want to include all the dependencies with a.*:*:* with
classifier = foo and rest of them should be without classifier
one op
Hmm, I hadn't considered that possibility.
I'm using Apache Maven 3.1.1, with maven-compiler-plugin 2.3.2.
On Tue, Nov 19, 2013 at 2:02 PM, Andreas Gudian wrote:
> (Just repeating what Vincent wrote already)
>
> When you invoke 'mvn test', you tell maven to run the default lifecycle up
> to pha
(Just repeating what Vincent wrote already)
When you invoke 'mvn test', you tell maven to run the default lifecycle up
to phase 'test', which _already_ includes the phases 'compile' and
'test-compile'. Check that link to the lifecycle documentation.
In your case, you probably used an older versio
Thanks all, that helps!
In the future, could `mvn test` automatically call `mvn test-compile` every
time, in case src/main/ code has changed that affects src/test/ code?
On Tue, Nov 19, 2013 at 1:09 PM, Vincent Latombe
wrote:
> Hi,
> you should use mvn clean test to make sure compilation happen
Hi,
you should use mvn clean test to make sure compilation happens everytime.
Otherwise, you can check recent versions of maven-compiler-plugin (3.1)
which introduced some incremental compilation support [1].
And yes, mvn compile will only compile main source code, you should check
the lifecycle r
You can call test-compile phase. mvn test-compile
On 19 November 2013 20:06, Ron Wheeler wrote:
> On 19/11/2013 12:27 PM, Andrew Pennebaker wrote:
>
>> I was refactoring some code, when I noticed unit test errors to do with
>> missing methods, as I had forgotten to also refactor my unit tests. T
On 19/11/2013 12:27 PM, Andrew Pennebaker wrote:
I was refactoring some code, when I noticed unit test errors to do with
missing methods, as I had forgotten to also refactor my unit tests. These
sorts of errors should have been caught at compile time, but `mvn test` was
blissfully running the tes
I was refactoring some code, when I noticed unit test errors to do with
missing methods, as I had forgotten to also refactor my unit tests. These
sorts of errors should have been caught at compile time, but `mvn test` was
blissfully running the tests anyway.
How can I force `mvn compile` to compil
Hi,
I tried changing the snapshot to be a later version
mvn -B -DdevelopmentVersion=52.0.1-SNAPSHOT -DreleaseVersion=52.0.0
-Dusername=* -Dtag=myproject-52.0.0 -DskipTests -P prod -Dresume=false
-DdryRun=true org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare
but I still get the
On 19/11/2013 10:50 AM, Russell Gold wrote:
The release plugin does an awful lot more than deploy. The usual case is that
during development, your version is set to a snapshot - the plugin changes it
to a release version, commits the change to CM and tags it, among other things.
Deploy won’t d
The release plugin does an awful lot more than deploy. The usual case is that
during development, your version is set to a snapshot - the plugin changes it
to a release version, commits the change to CM and tags it, among other things.
Deploy won’t do any of that.
That said, your point about th
I never us the release plug-in so you can take my comments with a grain
of salt.
From reading the docs I am not sure that these are right.
-DdevelopmentVersion=52.0.0-SNAPSHOT -DreleaseVersion=52.0.0
My interpretation is that you are trying to get maven to go backwards.
You are saying to rele
I wouldn't toss-off the idea that providing a POM can't be a security risk.
It *depends* what you are coding and what assets are being protected. True,
there is "a bigger problem at hand if someone knowing an internal server is
a security risk", but even if there's no risk today, the risk can be
to
I hadn't specified a Maven release version anywhere, so I assume you meant
like this
mvn -B -DdevelopmentVersion=52.0.0-SNAPSHOT -DreleaseVersion=52.0.0
-Dusername=* -Dtag=myprojectt-52.0.0 -DskipTests -P prod -Dresume=false
-DdryRun=true org.apache.maven.plugins:maven-release-plugin:2.4.2
I used (former employer) use a process akin to shade to publish "clean"
poms at an alternative groupId... it was OK but a bit of a pain
On 19 November 2013 14:47, Benson Margulies wrote:
> The security concern here is nonsense, at best it's 'security by
> obscurity'.
>
> However, there's a bett
The security concern here is nonsense, at best it's 'security by obscurity'.
However, there's a better reason to clean off the poms that happened
to us. Our product poms use our internal parent POM, which encodes our
chosen options for all the plugins we use at build time, and our
infrastructure (
I would of thought it would be better practice to keep a clean
separation between your pom.xml and settings.xml where any sensitive
server information goes in your settings.xml
However, if you are worried that someone knowing a URL to an internal
server is a security risk, then I would suggest you
22 matches
Mail list logo
