Re: Getting project classes from plugin

[Barrie Treloar]

On 5 September 2016 at 12:11, Christopher  wrote:

> Hi,
>
> I'm trying to write a Maven plugin which gets, and processes, a list of
> classes from the project. I want to be able to get the project classes
> compiled from either src/main/java (compile scope), and src/test/java (test
> scope, minus compile scope), depending on user configuration.
>
> So far, the closest things I've found to help me are (project is an
> instance of MavenProject):
> project.getCompileClasspathElements()
> and
> project.getTestClasspathElements()
>
> I then use that to build a URLClassLoader, which I then use Guava's
> ClassPath utility to find all the classes.
>
> The problem is, that brings in the whole classpath, and all I want is just
> the project's own classes, not those from dependencies (including Java
> itself). And, the test classpath elements includes the compile-time scoped
> items, as well, which I don't necessarily want. I could probably do set
> subtraction to remove the compile-time scope from the test scope, but I
> can't figure out how to get rid of what's being added as dependencies,
> which I don't wish to process. Perhaps I can do set subtraction from the
> dependencies? Is there a way to enumerate the classpath of just the
> dependencies?
>
> Has anybody done anything like this? Is there a better way to get only the
> project's own classes?
>

Why are you wanting to do this?

Are the output files in target/classes and target/test-classes not
sufficient?

Re: Maven and Eclipse

[Barrie Treloar]

On 9 June 2016 at 01:00,  wrote:

> Thanks Curtis!
>
> That's exactly what I did.
>
> As soon as I get a chance, I'll try a fresh install of Mars 2 and see how
> it goes.  I usually do my Eclipse upgrades with fresh installs, this is the
> first time I tried to upgrade from a previous version.
>
> Mike


And when you resolve the issue, can you post back your findings for search
engines to find.

Thanks.

Re: Maven and Eclipse

[Barrie Treloar]

On 8 June 2016 at 01:33,  wrote:

> I have recently been doing Maven builds from Eclipse Luna with no problems.
>
> Recently I upgraded Eclipse to Mars 2 and Maven builds that worked in the
> past no longer work.  I have posted the error I'm getting at the end of
> this email.  In addition, it appears that the Maven -> Update project
> Feature is no longer working.  When I do this from Eclipse Mars 2 on an
> empty local repo, the local repo is populated from my remote repo fine, but
> the Java Build Path Libraries are not populated, when I start with both an
> empty local repo and no libraries other than the JDK.
>
> I am using the m2e-workspace v0.3.1.  Does this need to be changed as a
> result of my upgrade from Luna to Mars 2?
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> (default-compile) on project queue.producer:
> Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile failed:
> Plugin org.apache.maven.plugins:maven-compiler-plugin:2.5.1 or one
> of its dependencies could not be resolved:
> Failure to find org.apache.maven:maven-plugin-api:jar:2.0.9 in
> https://swimrepo.faa.gov/nexus/content/repositories/Repo-jboss-fuse-06-02-01-Releases
> was cached in the local repository, resolution will not be
> reattempted until the update interval of SwimRepo
> has elapsed or updates are forced -> [Help 1]


Does this work on the command line ?
If yes, then you need to email the m2e mailing list to troubleshoot further.
https://dev.eclipse.org/mailman/listinfo/m2e-users

This error doesn't look like a problem with maven or m2e.
This looks like org.apache.maven:maven-plugin-api:jar:2.0.9 is not in your
organisations nexus proxy.

>From the path in the url to the nexus repo it looks like a jboss fuse cache.
My last recollection of the jboss caches were they were bastardized copies
of central to work with jboss.
I'd recommend making that cache the last thing the nexus proxy attempts to
check.

Re: Create own Maven repository

[Barrie Treloar]

On 13 May 2016 at 22:33, Ron Wheeler  wrote:

> Small technical correction on military notation.
>
> Are you sure that you did not mean FUBARed rather than SNAFU?\


This is Maven we are talking about, its definitely SNAFU.

Re: Create own Maven repository

[Barrie Treloar]

On 13 May 2016 at 22:33, Ron Wheeler  wrote:

> Small technical correction on military notation.
>
> Are you sure that you did not mean FUBARed rather than SNAFU?

Re: Create own Maven repository

[Barrie Treloar]

A snapshot repository won't behave how you think it will behave.
I recommend not providing one.

As a developer you want your code base to be in a known configured state.
Having a snapshot repository will mean that Maven will pull in a new
snapshot occasionally (you have some control over when they might be) and
if that snapshot is SNAFU then you have just stopped that developer from
being productive. If a developer wants a snapshot let them pull your code
down and built it themselves, then if the code is SNAFU they can choose a
previous revision from source control to use instead.

Since you are talking about a sourceforge project then you are providing an
open source, so you are better off deploying your releases to central.
Your users will thank you for not slowing their build times down with your
custom repo.

Re: An idea I had for one way of doing Continuous Delivery with Maven

[Barrie Treloar]

On 6 May 2016 at 09:48, Ben Podgursky  wrote:

> I see these discussions often, and I wanted to jump in and mention how we
> handle continuous deploys, because I feel that it avoids many of the
> downsides mentioned here, albeit with some (IMO) minor costs:
>
> - all of our internal dependencies are SNAPSHOT.  we do not do releases,
> ever, or ever depend on a fixed version
>
> - we attach to the package phase of our builds an assembly which packages
> the artifact and all of the  dependencies it tested against into a tar.gz
>
> - we deploy the tar.gz to our artifact server with a snapshot version (ex,
> MY_PROJECT-1.0-deploy.tar.gz)
>
> - when deploying we simply take the last snapshot deploy artifact and unzip
> it in production (+ some  config files etc).
>
> so while you use SNAPSHOT versions, you are guaranteed that you are
> deploying against tested dependencies.  and you never have to commit
> updated dependency versions, do releases, etc.  the only real cost is a bit
> of artifact server disk space… but disk space is incredibly cheap.


You left out tagging the source code in the built jars.

How are you supposed to pull up the code in production?
Or git bisect, or diff between versions to track down when a defect was
introduced?

Re: RESOLVED: R question (with context)

[Barrie Treloar]

On 14 September 2015 at 11:17, Martin Gainty  wrote:

> got it working and the apk deployable is ready to be tested
>
> Many Thanks to Stuart McCullough for his kind assistance on a rainy Sunday
> Martin


You dont provide any summary of the actual problem, once identified, and
then the correct resolution.

Make the internet a better place and leave these notes for others to find
when they face the same problem.

Re: AUTO: Warren Cook is out of the office (returning 09/14/2015)

[Barrie Treloar]

Is Warren related to Julia Antonova?

Re: Replacing a bunch of -Dkey=value pairs using external file

[Barrie Treloar]

On 9 September 2015 at 08:14, Dan Tran  wrote:

> Hi
>
> I have a scenario where I use a maven reactor multi-modules build to
> orchestrate a vmware OVA build from scratch ( start with ISO, create
> initial VM, apply additional provisioning, export to OVA, deploy, and test)
>
> The poms have properties which can be overridden  via -Dx=y to build on
> non-default environment, but there  are too many to account for
>
> So far I found
>
> http://www.mojohaus.org/properties-maven-plugin/set-system-properties-mojo.html
> but the initial experiment is not good.
>
> Perhaps, this feature must come from maven core? if so, is it a lot of
> effort to add this feature? and how?
>
> is there a similar need like this from Maven community?
>
> Advice is greatly appreciated
>

 Put the properties into a profile in ~/.m2/settings.xml and then activate
it via -P
e.g.

ci

true



mvn -Pci

With the profile activate rat will now be skipped.

Re: Replacing a bunch of -Dkey=value pairs using external file

[Barrie Treloar]

On 9 September 2015 at 10:08, jieryn  wrote:

> bash$ cat sys1.env
> -DZZ01=maven
> -DZZ02=rocks
>
> bash$ mvn $( ZZ02=rocks
> ZZ01=maven
> sun.java.command=org.codehaus.plexus.classworlds.launcher.Launcher
> -DZZ01=maven -DZZ02=rocks help:system
> MAVEN_CMD_LINE_ARGS= -DZZ01=maven -DZZ02=rocks help:system
>
>
Well done.
I was trying to use
env 'rat.skip=true' mvn -pl maven-scm-plugin validate

to do the same, but that was setting environment variables not command line
args.
MAVEN_OPTS also wasn't useful as that was for the java command not for the
mvn command.

I wasn't happy with offering this solution up because it became more
cumbersome to type, but storing these other configs in files and wrapping
them with basic scripts is doable

Re: Replacing a bunch of -Dkey=value pairs using external file

[Barrie Treloar]

On 9 September 2015 at 09:30, Dan Tran  wrote:

> Hi Barrie,
>
> That would work.  On caveat, I have to instruct my user to edit their own
> settings.xml.  Would be nice if I can just pass in -fp xxx from command
> line


Are they truly always on?

Then you can jam them in your pom.xml

http://maven.apache.org/pom.html#Properties

  
true
  

Re: Use 2 pom.xml files with different names

[Barrie Treloar]

On 10 August 2015 at 23:22, Alex Ditu ditu.alexan...@gmail.com wrote:

 Ok, look what I am trying to achieve: I have a project with 2
 profileDeployments (it produces 2 types of artifacts: a jar and a war)
 but from the same sources. So, I did the following thing: I have
 written 2 pom.xml files with 2 different names (for example: pom.xml
 and pom2.xml). When I want to build the .jar artifact I would use the
 command 'mvn deploy' when I want the .war artifact I would use: 'mvn
 -f pom2.xml' --- after this, I encounter the problem I mentioned
 earlier.

 Note that the artifactIds are different.


You solution is simple: do not have one project, split it into multiple
projects.

A war file should not have any java code in it. So there is no need for you
do be having two poms. You war project depends on the jar project and you
are done.

There are plenty of examples on how to do this in the freely available
maven books at http://maven.apache.org/articles.html

[ANN] 2015 Committer School for people who want to become Maven Committers

[Barrie Treloar]

It's time for the yearly committer school announcement.

If your company uses Maven, wouldn't it be good to convince them to spend
some of your time helping to make Maven better for them (and every one
else)?

If you use Maven, which of your itches do you think need scratching the
most? Find some spare time to make Maven a better tool.

Do you have knowledgeable non-technical people that could help contribute
too? Writing the documentation in a coherent way targetted to the specific
need of the user's skill level is hard. Ask you company to kick in by
assigning some talent to make understanding things better.

Read Stephen's blog post
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
and let us know.

Re: fixing an almost Maven project

[Barrie Treloar]

On 24 July 2015 at 12:18, Paul Benedict pbened...@apache.org wrote:

 It sounds like both your projects are snapshots. So when you build
 B-SNAPSHOT you have no idea what's inside of A-SNAPSHOT. If this is
 bothersome to you, you can think about releasing milestone versions of A so
 that B-SNAPSHOT always has a known/reliable codebase to work with. Perhaps
 you want weekly snapshots to be released, for example, but you definitely
 want to lock down A's version for B.


Alternatively you can have Jenkin's use a per-project ~/.m2/repository.

Before each build we delete the per-project .m2/repo so that previous
builds don't pollute it.
This does mean that each build requires every released version to be seeded
into your .m2/repo - but this is retrieved from a network local repository
server, so its mostly fast enough.

Now you can build your jenkins projects for A and B knowing that they have
their own .m2/repo and will build everything from source control.

However Paul's comment would be a better approach.
You should also think closely about release lifecylces, as the way you have
it setup now you will need to release project A and B at the same time, as
child projects should be released together with the parent.
I think the advise for git is to make the relationship 1 git repo : 1
release cycle.
That is, dont put A and B in the same git repo if you indent to release A
and B on different cycles.

Re: fixing an almost Maven project

[Barrie Treloar]

On 24 July 2015 at 13:33, V. Mark Lehky mark.le...@gmail.com wrote:

 Our release process is definitely: everything gets released at the same
 time (with the same version number).

 How do you create per-project .m2 repo via Jenkins?
 Is it just a case of deleting the repo before each build, or are there
 actually separate copies of repos on disk?


I won't claim that doing this is best practice.

You can't just delete the repo before each build, your machine has multiple
build threads right? So that would cause things to break.

There is an option in the jenkins config under Build  Use private Maven
repository

Help for feature: Use private Maven repository

Normally, Jenkins uses the local Maven repository as determined by Maven —
the exact process seems to be undocumented, but it's ~/.m2/repository and
can be overridden by localRepository in ~/.m2/settings.xml (see the
reference for more details.)

This normally means that all the jobs that are executed on the same node
shares a single Maven repository. The upside of this is that you can save
the disk space, but the downside of this is that sometimes those builds
could interfere with each other. For example, you might end up having
builds incorrectly succeed, just because your have all the dependencies in
your local repository, despite that fact that none of the repositories in
POM might have them.

There are also some reported problems regarding having concurrent Maven
processes trying to use the same local repository.

When this option is checked, Jenkins will tell Maven to use
$WORKSPACE/.repository as the local Maven repository. This means each job
will get its own isolated Maven repository just for itself. It fixes the
above problems, at the expense of additional disk space consumption.

When using this option, consider setting up a Maven artifact manager so
that you don't have to hit remote Maven repositories too often.

If you'd prefer to activate this mode in all the Maven jobs executed on
Jenkins, refer to the technique described here.
---

Note: we use the evil Maven build job.
Read
http://javaadventure.blogspot.com.au/2013/11/jenkins-maven-job-type-considered-evil.html
for more on this.

We got everything working - and haven't spent much effort refactoring this
stuff to best practices.

Re: fixing an almost Maven project

[Barrie Treloar]

On 24 July 2015 at 13:39, V. Mark Lehky mark.le...@gmail.com wrote:

 I should have added:
 Before I came along, everything got build as jar-with-dependencies. Test
 code did not live in src/test, but in src/main; and was, obviously, not run
 with 'mvn test', but with 'java -cp ...jar-with-dependencies.jar
 org.junit.runner.JUnitCore ...AllTests'. All of which I thought was rather
 brute. Bloatware, but it did work.
 Or was I wrong?


If your mailing to the Maven User list, be prepared to drink the kool-aid :)

I will say that what you have done has moved your project onto The Right
Path(tm).

Keep going, you'll get there.

Re: fixing an almost Maven project

[Barrie Treloar]

On 24 July 2015 at 13:30, V. Mark Lehky mark.le...@gmail.com wrote:

 So you're suggesting controlling this via version numbers?
 Have projectB depend on projectA:1.0.1-SNAP, while projectA is actively
 being worked on the next version, say 1.0.2-SNAP? Or something like that?


 On 07/23/2015 07:48 PM, Paul Benedict wrote:

 It sounds like both your projects are snapshots. So when you build
 B-SNAPSHOT you have no idea what's inside of A-SNAPSHOT. If this is
 bothersome to you, you can think about releasing milestone versions of A
 so
 that B-SNAPSHOT always has a known/reliable codebase to work with. Perhaps
 you want weekly snapshots to be released, for example, but you definitely
 want to lock down A's version for B.


He is saying:

projectB depends on projectA:1.0.1 (Note the lack of -SNAPSHOT).
and
projectA dependon on projectB:1.0.2 (again no snapshot).

So at regular, and determined intervals, you merge your work back onto HEAD.
When you do, cut a release - they are free and cheap, you can just create
as many as you need.
Then your branch projects can decide when they want to move to the point
releases.
That way they are isolated from each other, have a known release state, and
can easily switch back to previous versions when a release is deficient.
You won't be able to do this with the SNAPSHOT approach.

Re: Skill set to maintain a enterprise build system using Maven

[Barrie Treloar]

On 1 June 2015 at 09:40, Dan Tran dant...@gmail.com wrote:

 For my case, I am very fortunate to involve with the the product from early
 day (a year ba ck) and Maven is embraced to the max where plugins are
 developed to solve every build use case in a full dev/qa/releng integration
 pipeline. The developments are multi-sites and  heavily depending Maven
 Central like repository cluster and Maven release plugin.

 The odd thing to me is it is hard to find Java talent with a passion for
 build/ci with Maven, and it is also  hard to switch perl/python devops into
 java to maintain Maven build.  am I wrong here?


The odd thing to me is it is hard to find *any* talent with a passion for
build/ci with *anything*.

FTFY.

Its a niche market, and one that lots of people still dont see the value in.
Getting them to be excited about something tangential to development is
difficult - its like eating healthy and excerise, people know they should
be doing it but they aint.

I *still* see people attempting to develop software with no version
control, and hand crafted outputs from IDEs on their local machines.
We even get contractors coming in wanting to use VMs in dev that they
promote into production *shudder*.

They best you can do is to hope you can train your people internally about
why this is all good.

I'm sure I've said it before, but part of Maven's problem is that this is
all magically taken care of behind the scenes and less people need to know
how it works to make it work.
The downside is that there are then less people who can fix things when
they need fixing.

Re: about the bug

[Barrie Treloar]

Please use the Maven users list for these questions.

On 30 April 2015 at 11:47, Pengfei Deng pengfei.d...@ericsson.com wrote:

  Hi all ,

 When I try to use maven-release-plugin and use

 release:clean release:prepare release:perform I got error below:



 [INFO] [INFO] --- maven-site-plugin:3.4:deploy (default-deploy) @
 site-deploy-test ---

 [INFO] Unable to connect to agent:
 com.jcraft.jsch.agentproxy.AgentProxyException: connector is not available:

 [image:
 https://eis-jenkins-jcat.rnd.ki.sw.ericsson.se/static/09e72bc8/images/spinner.gif]



 And the source code is like this:



try

 {

 Connector connector = ConnectorFactory.getDefault().
 createConnector();

 if ( connector != null )

 {

 IdentityRepository repo = new RemoteIdentityRepository(
 connector );

 sch.setIdentityRepository( repo );

 }

 }

 catch ( AgentProxyException e )

 {

 fireSessionDebug( Unable to connect to agent:  + e.toString()
 );

 }

 Could you please help?



 Best Regards,

 [image: Ericsson] http://www.ericsson.com/

 *PENGFEI DENG *
 Software Design Engineer

 BURA DURA RCI CBC Tools JCAT and Config


 *Ericsson*
 No.5 WangJing East Road Chaoyang District Beijing
 100102, China
 Phone +86 15652957083

 Office +86 10 84767195
 pengfei.d...@ericsson.com
 www.ericsson.com



 [image: http://www.ericsson.com/current_campaign]
 http://www.ericsson.com/current_campaign



 Legal entity: CBC/XIT, registered office in RndP. This Communication is
 Confidential. We only send and receive email on the basis of the terms set
 out at www.ericsson.com/email_disclaimer

Re: Do people actually use markdown or should I abandon it and migrate to xdocs?

[Barrie Treloar]

Hervé thanks for spotting someone had problems that may be
un-addressed, I completely missed following that through.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Do people actually use markdown or should I abandon it and migrate to xdocs?

[Barrie Treloar]

On 13 March 2015 at 11:05, Kevin Burton bur...@spinn3r.com wrote:
 Thanks.  IF these are used in big projects like this I’ll probably just
 migrate.

Wasn't there some talk about using reStructuredText at some stage?

I'm only just tinkering with that now on other projects so I have not
investigated whether the Maven pipeline supports it.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How do I target tests in submodule when building parent project?

[Barrie Treloar]

On 24 January 2015 at 10:54, Jeff predato...@gmail.com wrote:
 The rest of the modules are specific to testing a certain functional
 areas.  I need to check out and build the whole multi-module project, but I
 only want to run a subset of tests from one specific submodule.

Why?

You should be doing all or nothing.

If they are unit tests they should run fast and therefore have
neglible impact on your build times.

If they are integration tests then they should be in their own module.
If you then exclude the integration test module from the parent it
will not run the integration tests and not impact developer build
times. You place the modules in a profile and have Jenkins enable it
to run the tests. If the developers also want to run them they can
enable to profile on the command line.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolving classpath hell issues by allowing libraries to only use the version they request?

[Barrie Treloar]

On 6 January 2015 at 14:50, Ron Wheeler rwhee...@artifact-software.com
wrote:

 On 05/01/2015 6:29 PM, Kevin Burton wrote:

 Breaking your application into smaller independent services may give you a

 way to reduce the number of conflicts related to these different
 transitive
 dependencies but that may not be as easy as testing your app with the
 updated versions or doing some research with the teams that are building
 with the old libraries to see if they will upgrade and run their
 acceptance
 tests within a time frame that meets your project's timeline
 requirements.


 I agree.  in this case the issue is testing. I need to embed cassandra so
 I
 can test it but it’s conflicting with spark.

 These are both Apache projects that I don't know.


Same.

Or alternatively from my brief reading of these two it appears that they
can run independently.
If you can avoid having them running in the same process you can separate
out your dependency hell.

This may be as simple as creating a new module to do your integration
testing and to control starting the external dependencies needed to do your
integration testing.

Re: Separating Integration and Unit Tests

[Barrie Treloar]

And put your integration tests in another module, that way it can depend
upon the completed results of what you want to integrate and you wont have
to muck around with separating your unit tests from it (since you will
*only* have integration tests in this module)

On 2 January 2015 at 13:55, Benson Margulies bimargul...@gmail.com wrote:

 I think that what you actually want is two executions of surefire (or
 one of surefire and one of failsafe) with different test name
 patterns.

 On Thu, Jan 1, 2015 at 2:40 PM, Ole Ersoy ole.er...@gmail.com wrote:
  Hi,
 
  I'm attempting to separate my integration and unit tests using profiles
 and
  the maven build helper plugin.  I have unit tests in the standard
 directory
  and integration tests in `src/integration-test/java`.  When I run the
  default profile, I expect integration tests to be skipped and unit tests
 to
  be executed.  When I run the `integration-test` profile with `mvn clean
 test
  -Pintegration-test` I expect the integration tests to be run and the unit
  tests to be skipped.  Right now Maven is just ignoring the profile test
  settings:
  `skip.integration.tests`
  `skip.unit.tests`
  and it just runs all the tests regardless of which profile is active.
 
  My POM looks like this:
 
  project xmlns=http://maven.apache.org/POM/4.0.0;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/maven-v4_0_0.xsd;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  modelVersion4.0.0/modelVersion
 
  groupIdcom.example.maven/groupId
  artifactIdseparating-integration-and-unit-test-execution/artifactId
  version1.0.0/version
 
  profiles
  profile
  idunit-test/id
  activation
  activeByDefaulttrue/activeByDefault
  /activation
  properties
  skip.integration.teststrue/skip.integration.tests
  skip.unit.testsfalse/skip.unit.tests
  /properties
  /profile
  profile
  idintegration-test/id
  properties
  skip.integration.testsfalse/skip.integration.tests
  skip.unit.teststrue/skip.unit.tests
  /properties
  /profile
  /profiles
  build
  plugins
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdbuild-helper-maven-plugin/artifactId
  version1.9.1/version
  executions
  !-- Add the integration-test source directory --
  execution
  idadd-integration-test-sources/id
  phasegenerate-test-sources/phase
  goals
  goaladd-test-source/goal
  /goals
  configuration
  sources
  sourcesrc/integration-test/java/source
  /sources
  /configuration
  /execution
  /executions
  /plugin
  /build
  /project
 
  Thoughts?
 
  TIA,
  - Ole
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-- 
Buy your books from me and Book Depository at
http://www.users.on.net/~baerrach/
Commissions go to http://www.plan.org.au/

Re: Separating Integration and Unit Tests

[Barrie Treloar]

You can even use your profile still with this way.

You stick the module definition into the profile.
It does mess with releases; either you enable it with the release (in which
case the release may slow down), or you leave it disabled which means that
the version number doesn't get automatically bumped (just fix it up
manually).

On 2 January 2015 at 14:44, Ole Ersoy ole.er...@gmail.com wrote:

 Hi Barrie,

 Good tip - I'll keep it in mind.

 Thanks,
 - Ole


 On 01/01/2015 09:54 PM, Barrie Treloar wrote:

 And put your integration tests in another module, that way it can depend
 upon the completed results of what you want to integrate and you wont have
 to muck around with separating your unit tests from it (since you will
 *only* have integration tests in this module)

Re: Little documentation issues

[Barrie Treloar]

On 17 December 2014 at 12:24, Ron Wheeler rwhee...@artifact-software.com
wrote:

 One of the wonderful features about Maven is that no matter how long one
 has been using it or how much one has studied Maven documentation , one
 still feels the necessity of ending every assertion about how it works with
 (If I have that right.) .

 I am so happy to not be alone!


You are not the only one (If I have that right)

Re: Maven Repositories settings best practice

[Barrie Treloar]

On 12 December 2014 at 11:53, Dan Tran dant...@gmail.com wrote:

 I found this

 http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/#.VIpCmTHF_AQ

 sorry about the noise


If you can't find it in the official docs, then feel free to hack up some
enhancements.

Re: Maven Repositories settings best practice

[Barrie Treloar]

On 12 December 2014 at 15:10, Dan Tran dant...@gmail.com wrote:

 Where is in the official doc, this should land?


That's an awfully good question.
There is another thread about re-organising the documentation.

The User Centre (http://maven.apache.org/users/index.html) docs are pretty
thin, but I would expect this advice to land in there.

Or perhaps the Run Maven  Configuring Maven (
http://maven.apache.org/guides/mini/guide-configuring-maven.html) has a
section on Mirrors that links to
http://maven.apache.org/guides/mini/guide-mirror-settings.html.
The first sentence says Repositories are declared inside a project, which
means that if you have your own custom repositories, those sharing your
project easily get the right settings out of the box. which runs against
the current advice.

Unfortunately those mini-guides dont have a hierarchy available on the left
hand navigation page and hacking the URL to drop of the last path just
gives a blank page.

Re: [LOGO] site with Fluido skin and owl logo

[Barrie Treloar]

On 26 November 2014 at 18:55, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:


 I also think we should remove the side-bars (and perhaps switch to a top
 bar menu) as they hinder mobile accessibility.


I think the total number of people using a mobile phone to visit the maven
website would be zero.

I think the left side bars is useful, but too cluttered.
The right side bar is also useful because it has all the related links but
takes up a lot of room.

At the moment the focus is on a new user, which most people are once in
their Maven experience.
We should make it easy for the new user to find the landing page for
download and the new user tour, and then redesign the front page for the
most common purpose of using Maven.  The develop Maven page should be
pushed onto another landing page too.

This would allow the use of larger, more readable fonts as well as there is
less clutter.
I'm no web design guru, but all the online courses I've been reading over
the last 6 months have had the Maven site redesign in mind.

Re: explicit dependencies in maven

[Barrie Treloar]

On 6 November 2014 22:15, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi,
 On 11/5/14 11:14 PM, Barrie Treloar wrote:

 On 6 November 2014 05:37, Karl Heinz Marbaise khmarba...@gmx.de wrote:

  Hi,

 to be clear on that point you should never change released versions.

 The idea of releases is that they are immutable.

 The scenario you have described should never be done which means:

 If you change code than make simply a new version like 1.2 or may be
 better things like 1.1.1 to show it's a bug fix release of 1.1 etc.

 You should prevent of doing developers such a thing...



 Read http://semver.org/


 Should that change something ? Or do i misunderstand something ?


No, just more reading for Irfan.

Re: explicit dependencies in maven

[Barrie Treloar]

On 6 November 2014 05:37, Karl Heinz Marbaise khmarba...@gmx.de wrote:

 Hi,

 to be clear on that point you should never change released versions.

 The idea of releases is that they are immutable.

 The scenario you have described should never be done which means:

 If you change code than make simply a new version like 1.2 or may be
 better things like 1.1.1 to show it's a bug fix release of 1.1 etc.

 You should prevent of doing developers such a thing...


Read http://semver.org/

And the freely available books at http://maven.apache.org/articles.html

Re: [pre-verify over deploy]

[Barrie Treloar]

On 3 November 2014 20:07, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 Well I knew I'd written something on that topic... but re-reading I am
 surprised at how much information I managed to cram in there without it
 feeling over dense (for me)

 BTW I am of the *never deploy -SNAPSHOTs* camp but I recognise that there
 are other people out there... and I have to interact with them some times
 and that post is helpful to explain things to them!


I think its important for people to try things, because this stuff is
complicated, and unless you get yours hands dirty it is difficult to
understand and get a feel for why it doesn't work.

After you have been burnt by a dependency being updated from underneath you
- one that you have your own changes in - then you realise that you need to
build twice to rebuild the other snapshot to keep going, and that the
other developers haven't gotten their head around the build process and why
things sometimes dont work... It makes life simpler to avoid deploying the
snapshots for developer consumption.

Re: Best way to blacklist repository (maven.glassfish.org in site build)

[Barrie Treloar]

mirror
  idCentral/id
  urlhttp://repo1.maven.org/maven2/url
  mirrorOf*/mirrorOf
/mirror

Have you tried redirecting everything to Central via a mirror?

Alternatively you can setup a Maven Repository Manager (MRM) locally
(even on your laptop) so that it no longer matters if there are
repository abuses in the pom,
Maven will only contact your local MRM and avoid multiple, slow,
network connections for each defined repo.

Re: [pre-verify over deploy]

[Barrie Treloar]

On 29 October 2014 20:18, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:


 http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html


Thanks for writing that up!
I'll remember to point people there instead of having to remember
half-baked stuff and type :)

This is a useful piece of advice
especially in conjunction with the Versions Maven Plugin
http://mojo.codehaus.org/versions-maven-plugin/lock-snapshots-mojo.html which
has goals for “locking” and “unlocking” your -SNAPSHOT dependencies to the
current timestamp version, thereby removing uncertainty. 
It will allow you to live dangerously on shifting sands and then when you
get sucked under to go back and lock to a working version.
But I still think you are better off avoiding that problem in the first
place.

Re: [pre-verify over deploy]

[Barrie Treloar]

On 29 October 2014 18:48, Fay Wong philip584...@gmail.com wrote:

 Many thanks to Barrie.

 I think what you have clarified is the normal flow of maven practice.

 The deploy in the context of my previous post means: our developer invoke
 a mvn deploy command to share the output(bytecode) through the repository
 so as to shorten the build time of whole project(as its code base is too
 large). Our goal is modular compiling and packaging.

 Currently my pain is our developer would deploy broken bytecode to our dev
 repository and broken others work. Could i define a intermediate
 repository, everytime they deploy, jenkins will verify it. if pass, then
 depoy it into dev repository, otherwise, revert the intermediate repository
 to keep sync with dev repository.

 Is there a easier way to achieve this?


There is the stick, or the carrot.

The paid version of Nexus (a Maven Repository Manager) has staging
repositories, I dont use them, you may be able to get them to do what you
want.

Either way its a process issue.
Teach your developers to stop breaking the build.
Or use one of the options I've suggested.

Re: [pre-verify over deploy]

[Barrie Treloar]

On 30 October 2014 08:38, Curtis Rueden ctrue...@wisc.edu wrote:

 Hi Fay,

  Could i define a intermediate repository, everytime they deploy,
  jenkins will verify it.

 Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins
 has deploy permission to your remote repository. So your devs can no longer
 run mvn deploy from the CLI and expect it to work, but instead just push
 to master (or whatever integration branch) and then Jenkins runs the build.

 Once Jenkins does your deploys, you can set up your jobs to test for more
 stringent conditions before actually doing the deploy. E.g.:

 $ git clean -fdx
 $ mvn clean install
 $ bin/verify-artifacts.sh
 $ mvn deploy

 And verify-artifacts.sh does whatever further programmatic testing you
 need.

 OTOH, in many cases, you don't need a shell script -- often times, you can
 get what you need using Maven plugins like Surefire, Failsafe, and
 Enforcer. If you go that route, it might be enough so that devs running
 mvn deploy won't deploy bad stuff to the repo by default (unless they are
 aggressive enough to run e.g. mvn -DskipTests deploy which would be
 pretty bold).

 Regards,
 Curtis


Whether its Jenkins, or a developer, you've still pushed a release that
could break the build.

This is where you need some isolation available to your workflow.

Stuff breaks - it happens, Fay needs to determine how they want to deal
with it.

Re: [pre-verify over deploy]

[Barrie Treloar]

On 29 October 2014 14:00, Fay Wong philip584...@gmail.com wrote:

 Hi all,

 Is there any solution to pre-verify the deploy before it actually got into
 the repository?

 Take this usecase for example:

 In a team of 40 developer, every developer will deploy their module at any
 time, once there's a error,

 the final output software won't work and blocks other developer's flow.

 So is there any pre-verify solution(such as jenkins CI-server) to be
 enforced before the deploy overlapped the previous deploy?


Not really, this is a process issue.

You need to decide what is in a state of flux, and then when people should
consume it.

I'm assuming by deploy you mean a released artifact and not a snapshot
one.
Generally, you should not be deploying your snapshots for consumption by
other developers, as snapshots could break at any time and you impact
anyone who depends upon them.
Instead, when a developer needs a snapshot version they check out the code
and building it themselves, then when they need to import new changes they
pull in the changes to the code and rebuild. That way the developer gets to
choose when they will consume potentially breaking changes.

If these are released artifacts then you have lots of choices on how to do
this.
*) By using your version control system and some form of isolation (e.g.
branches).
   When the new version is released the developer still needs to pull those
changes in, and if there are breaking changes can revert back to the
previous version.
*) Have someone in a QA role validate that the artifact works prior to
promoting that version in you parent pom.

The act of deploying into your Maven Repository is independent from the
consumption of that artifact, it shouldn't be breaking peoples build until
they start using it.

Re: How to create ISO image that supports long file names?

[Barrie Treloar]

On 21 October 2014 08:12, David Hoffer dhoff...@gmail.com wrote:

 I'm trying to use iso9660-maven-plugin to generate an iso image and I'm
 getting string index out of range errors.  My input has long file names,
 e.g.

 7b0a8ad702ee0be0b971a082023550bd71bd33d3cbb4fa17f1de6af66f1871d4-comps-Server.x86_64.xml.gz
 and I suspect this is causing the problem.

 How can I resolve this?  I don't technically need/want an 9660 image as I'm
 creating DVD images (actually these will be used by vSphere and I think
 it's quite tolerant of ISO format).  Is there a way to configure
 iso9660-maven-plugin to allow long file names or is there a different
 goal/plugin that I should be using that supports this?  Currently I'm
 running the 'iso' goal on iso9660-maven-plugin.

 Example error:
 Execution generate-iso of goal
 com.github.stephenc.java-iso-tools:iso9660-maven-plugin:2.0.0:iso failed:
 String index out of range: -2


This is the Maven users list.
We don't own that plugin, you might try contact the author of that plugin
https://github.com/stephenc/java-iso-tools/commits/master/iso9660-maven-plugin

(Although Stephen is here as well this isn't the place for that discussion)

Also you might want to try
mvn -X
as that will give you more debug output to pinpoint your problem.
Plus you might want to clone that plugin and provide back a patch for your
problem.

Re: How to create ISO image that supports long file names?

[Barrie Treloar]

On 21 October 2014 09:20, David Hoffer dhoff...@gmail.com wrote:

 Hum, why isn't the Maven user list the right place to ask about how to use
 Maven to create an iso?  I'm not saying I have to use that plugin to do the
 job, just looking for input on how to do this regardless of the plugin.


If you want to ask general questions on how to do something in Maven sure,
then this is the place.

If you want to know why a particular plugin has problems and how to solve
them and its not one the Maven community is responsible for, then you would
get better help from the correct owners of that plugin.
The chances of someone here knowing the correct answer is much lower than
asking at the correct place.

In your particular case, building an ISO image is not strictly part of the
Maven lifecycle, and the amount of people who know how to do that will be
limited. YMMV.

You could try using the Assembly plugin (
http://maven.apache.org/plugins/maven-assembly-plugin/) to layout your ISO,
but you will need another tool besides Maven to create the ISO image.
You can use any other these to invoke external tools and bind them to the
Maven Lifecycle (
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
):
* Maven Ant Run plugin (http://maven.apache.org/plugins/maven-antrun-plugin/),

* Exec Maven plugin (http://mojo.codehaus.org/exec-maven-plugin/)
* Write your own plugin (http://maven.apache.org/plugin-developers/)

You probably want to create a separate module that creates the ISO image
from previously completed modules, and attach your ISO building to the
package phase.

Re: Request for functionality in maven-assembly-plugin - ignoreProjectBuildFilters

[Barrie Treloar]

On 13 October 2014 17:08, Tony Jewell tony.jew...@cregganna.com wrote:

 Thanks Karl,

 Two things:


1. I couldn't get access to the JIRA to submit a ticket myself - is this
something I am allowed to request?


Yes, you have to do something non-intuitive to get access. It should be
documented somewhere but I dont recall.
On https://jira.codehaus.org/secure/Dashboard.jspa up at the top left there
is the menu drop down, and you need to click Xicrles (
http://xircles.codehaus.org/)
You need to signup there.
This is because the Maven Jira isn't hosted at Apache.


2. Of course I'm going to ask: when is maven-assembly-plugin:2.4.2
likely to be released?


That's something a committer can do for you.
You might get lucky and Karl will do that as well.

Re: Request for functionality in maven-assembly-plugin - ignoreProjectBuildFilters

[Barrie Treloar]

On 13 October 2014 19:12, Tony Jewell tony.jew...@cregganna.com wrote:

 Thanks Barrie,

 Have now created login on Xicrles

 A 2.4.2 release would be really cool as we are currently blocked on this
 and I'd rather not use patched plugins in our build.


Somewhere on the internet is my notes for creating local patched releases
for this exact scenario, and allowing you to upgrade to the official one
when it comes out.
I'm at home at the moment and I can't find those notes!
They should be somewhere obvious - like on the Maven site, the wiki or in
the achives, but my google fu is failing me right now.
...
Damn, writing this email made me try harder.
Its here http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
but its really old and probably still ok, but just check before you use it.

Re: How do I test client and server since they form circular dependencies?

[Barrie Treloar]

On 9 October 2014 13:49, Bernd Eckenfels e...@zusammenkunft.net wrote:

 Am Wed, 8 Oct 2014 19:53:20 -0700
 schrieb Kevin Burton bur...@spinn3r.com:

  maybe one idea is to build a meta-module like foo-client-server-test
  which as a dependency on foo-client and foo-server.  then they could
  each test each other?  Seems a bit of a hack but it should work ..

 Yes, have an integration test module in your reactor which depends on
 both. Thats not a hack, is a good way to do that.


A circular dependency is normally a sign that you haven't got your
separations right.

In order to run your test you need to use both the server and client, that
sounds like a dependency to me!
And so you need a new module to express that dependency in.

Re: Need help regarding apache maven

[Barrie Treloar]

 Uploading: 
 https://sachin/svn/demo/com/kedb/kedb/0.0.1-SNAPSHOT/kedb-0.0.1-20140929.030730-3.jar
 Uploading: 
 https://sachin/svn/demo/com/kedb/kedb/0.0.1-SNAPSHOT/kedb-0.0.1-20140929.030730-3.pom

Is https://sachin/svn/ your SVN server?

You can't get Maven to deploy your artifacts to your SVN server.
Or at least if you can, it's not something I would recommend.
http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html
doesn't yet have this documented either.

You want to deploy your artifacts into a Maven Repository Manager, see
http://maven.apache.org/repository-management.html

Re: Tell maven to not have the parent pom as a dependency?

[Barrie Treloar]

On 14 September 2014 16:01, Mark Derricutt m...@talios.com wrote:

 You don't need N windows, I just add the pom in the maven projects tool
 window, and have open in my generated IDEA project my core project, plus
 any F/OSS project I may be forking/working on in the process.

 Find Anywhere then works across all projects.


This is the fake aggregation project we talked about.
This one DOES NOT get checked into the repository.
It's just something you create to link all these together for your
convenience.

The is a vaporware project that would help you manage this stuff, whenever
you turned one of your dependencies into a SNAPSHOT then it would download
the source for that project and put it correctly in your IDE and update the
fake aggregator to include it.

But no one has had enough of an itch to work on that project.
Sounds like you might find that useful Kevin, want to build it?

Re: Tell maven to not have the parent pom as a dependency?

[Barrie Treloar]

On 13 September 2014 02:46, Kevin Burton bur...@spinn3r.com wrote:

 OK… so this definitely works and the aggregation model compiles my module.

 But I need a way to bump the version number because I have complex
 dependencies and updating 10 places every time I change the project version
 isn’t going to be fun.


If you have 10 places where the dependencies need changing you are doing it
wrong.

You should have zero version definitions in your modules.
All version definitions are in the topmost parent pom in the
dependencyManagement section.
If you have a bunch of things that share versions, you can also create a
property and then use something like ${mygroup.version} so that you only
need to update the property section once.

Have you read the freely available Maven books?
It's been long while since I've read them but I think this advice is in
there.

Re: Tell maven to not have the parent pom as a dependency?

[Barrie Treloar]

On 12 September 2014 12:55, Kevin Burton bur...@spinn3r.com wrote:

 I have an OSS module in a multi-module maven project.

 I want to post this to a public repo… it’s open source.

 The problem is that the parent module is not OSS.

 When I setup a dependency it pulls in my OSS module just fine, but then
 it tries to pull down the parent module, which isn’t in the repo, and
 breaks.

 The parent pom isn’t really a dependency… so I’d like it to not need it

 is this possible?


As Dan says, make it a stand alone project.
i.e. Dont make it a module.

Being a module has a special meaning - treat this as part of a bigger
whole.
It also help with syntatic sugar by allowing you to run one command at the
top and have it propogate into all the modules.

To be complete a module has nothing to do with dependencies or dependency
management.

The reason your OSS module is pulling in the parent is not because of
dependency, but because of inheritance of the parent hierarchy.

Usually all modules are released together and will share version
identifiers.
If they are released independently then you normally wont make them
modules, and their version identifiers can do their own thing.
There is a recent post Maintaining versions in a multi-module project
that Stephen answers, you might also want to search the archives on this
topic as well.

A parent pom can be used in two ways; 1) to share common information i.e.
inheritance 2) keep related artifacts together to make working on a bug
that traverses artifacts easier i.e aggregation

In your case I dont think you need to use aggregation, you just need to
pull out the OSS artifact into its own stand alone location and then
include it as a normal dependency in your non-OSS project.

If you find that you are also fixing bugs in the OSS project at the same
time you are working on the non-OSS one, then you might want to create an
aggregate pom that has two modules (one OSS, the other non-OSS) so that you
can run maven commands in one place against both projects. Stephen Connolly
has some stuff somewhere about that I think.
The freely availble Maven books might also go into this in more detail, but
it tends to be a more advanced feature not well described.

Cheers
Barrie

Re: maven 3.1.1 crashes on GC overhead limit exceeded with millions of org.eclipse.aether.graph.DefaultDependencyNode

[Barrie Treloar]

On 27 August 2014 17:05, Juven Xu juvens...@gmail.com wrote:

 after enabling debug log I got 1.1G log full of lines of this:

 [DEBUG] Using mirror tbmirror (
 http://mvnrepo.taobao.ali.com/mvn/repository) for
 sonatype-nexus-snapshots (
 https://oss.sonatype.org/content/repositories/snapshots).


Have you confirmed that your mirror is working as expected?

Welcome Karl Heinz Marbaise to the Maven PMC

[Barrie Treloar]

I'm pleased to announce that the Maven PMC has voted to add Karl to the
Maven PMC.

Welcome, Karl.

Re: Remove old snapshots under local repository

[Barrie Treloar]

What's wrong with just blowing away ~/.m2/repository ?

If you have a local Maven Repository Manager it doesn't take very long to
reseed it.
(At least less time in aggregate than thinking of ways to prune snapshot
files in the repository correctly...)

Re: Doxia Eclipse Editor Plugin problem with snippet macro

[Barrie Treloar]

On 16 August 2014 00:49, Dan Tran dant...@gmail.com wrote:

 Markdown is the way to go, there is a conversion as well [1]


How do you use snippets in Markdown?
http://daringfireball.net/projects/markdown/syntax doesn't have anything
mentioned.
Is it under different terminology?

Re: Java SSL dependency issue

[Barrie Treloar]

On 8 August 2014 03:32, Joshua Bailey joshualbai...@gmail.com wrote:

 I have two branches of code. One compiles without a hitch, the other
 complains about this:

 Failed to execute goal
 org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
 (default-compile) on project thebookgrove-catalog: Compilation failure:
 Compilation failure:
 [ERROR]
 /Users/joshua/Desktop/Data/TheBookGrove/Platform/thebookgrove-catalog/src/main/java/com/thebookgrove/catalog/InternetConnectionAgent.java:[40,23]
 package sun.security.ssl does not exist
 [ERROR]
 /Users/joshua/Desktop/Data/TheBookGrove/Platform/thebookgrove-catalog/src/main/java/com/thebookgrove/catalog/InternetConnectionAgent.java:[147,29]
 cannot find symbol

 I couldn't find any help with Google, so you are my last resort :(



Option 1)

It's been a while since I tinkered in the security spaces but...
Are you sure you should be using sun.* packages?
These are normally internal implementation stuff.
You should be using the java.* interfaces instead.
(http://openjdk.java.net/groups/security/ sums this up - and
http://docs.oracle.com/javase/7/docs/api/ doesn't like JavaDoc for sun.*
stuff)

Option 2)

Guesses are that the two branches are using different environments.

Run mvn -X on both branches piping output to a file.
You can start with diff to see whether you get lucky and spot the problems.
Otherwise, its a line by line comb to see what the differences are and
whether these are the cause of your problems.

Are you building with a non-Oracle jdk in the second branch - which
obviously wont have the sun.* implementation stuff.

Re: testing-harness plugin: LocalRepositoryManager is not set

[Barrie Treloar]

On 24 July 2014 01:08, Vincent Zurczak vincent.zurc...@linagora.com wrote:


 Hi,

 I am not sure this is the right mailing-list.
 Maybe I should have posted to the dev list. Anyway...

 I have started working on new Maven plug-in last week and I have set up
 unit tests using the testing-harness plugin.
 I have problems with Maven injected fields, such as the Maven project.


Here will do, the devs are on both.

(and you will have to wait for someone with more knowledge about using the
testing harnesses)

Back when I was trying to use them you had a choice of 3, I think its not
down to one but I dont know if the documentation on how to set it up and
use it is readily available.

When you get your answers, would you add to the knowledge base?
It is always good to get fresh eyes on these things as the people who
already know what's going on make assumptions that someone just starting
out need to know about.

Re: How to change snapshot artifacts timezone?

[Barrie Treloar]

For your CI you need a repository for snapshots so that you can pull them
in after the local maven repository cache is cleared.
But for developers you dont want them pulling snapshots from a repository.

The reason is that Developer B pushes a snapshot of something you require,
and guess what, they broke the interface/implementation of that jar, and
now you can no longer work until you fix that snapshot.
You want your developers in control of when and how often they update their
snapshots, which generally means that they manually rebase from source
control and build the snapshot jars locally.




On 27 June 2014 10:15, Ben Podgursky bpodgur...@gmail.com wrote:

 IIRC snapshot timestamps are all explicitly set to UTC regardless of
 location, so that a snapshot published earlier on a machine in a later
 timezone does not accidentally override a snapshot published later from an
 earlier timezone.  I don't think you want to change this behavior (and
 probably can't).


 On Thu, Jun 26, 2014 at 4:04 AM, Aleksi Grönlund kvarta...@gmail.com
 wrote:

  I am using Maven version 3.0.4 and Nexus repository where to deploy Maven
  created snapshot artifacts. How I can change snapshots timestamp timezone
  from UTC to Europe/Helsinki ?
 
  I have tried to set timezone with following JAVA_OPTS and MAVEN_OPTS but
  those does not help with this issue. Any ideas?
 
  JAVA_OPTS=-Duser.timezone=Europe/Helsinki
  MAVEN_OPTS=-Duser.timezone=Europe/Helsinki
 
  Br,
  Kvartal00
 




-- 
Buy your books from me and Book Depository at
http://www.users.on.net/~baerrach/
Commissions go to http://www.plan.org.au/

Re: Complex Maven projects - Tutorials? Books?

[Barrie Treloar]

On 14 June 2014 02:14, Robert Kuropkat rkurop...@t-sciences.com wrote:

 On 06/13/2014 10:27 AM, Mark H. Wood wrote:

 On Fri, Jun 13, 2014 at 09:23:31AM +0930, Barrie Treloar wrote:

 On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote:

  So how does this book help you any more than all the detailed online
 Maven
 docs that exists and are updated?


 It's just another source of information.

 The docs don't really walk you through everything, they are mostly
 focused
 on a particular plugin and not on how to pull all this together.

 Indeed.  One thing I really miss from the evil old mainframe days is
 the manuals that gave you the big picture and the developers' view of
 how they expected the tools to be used.  There were usually two books
 for any product:

 o  Reference Manual -- *complete* individual descriptions of each feature,
 command, and qualifier.

 o  Programmer's (or User's) Guide -- fits all the pieces together and
 suggests good ways to think about the facility under discussion.

 I typically had both open when working on anything nontrivial.  It's
 essential to have both the macro and the micro view of a tool, to use
 it well.


 I'll add my cry of despair here as well.  Modern Open Source documentation
 efforts tend be mostly disappointing.  First of all, it's never in a nice
 neat collection.  Second, most of the articles and examples supplied by
 Senior Mentor Google are stale, trivial and sparsely explained.
  Explanations are rarely more than a statement of the obvious (Property:
 enabled:  true/false - enable or disable feature).  The question of WHY is
 rarely addressed and downstream results never.  Even if you do find a well
 detailed example it is very specific (cookbook style) with little
 explanation of the options NOT chosen and why.

 I'm running into this right now in fact.  I did some proof of concept
 testing on a bunch of plugins for my group, things looked good and now I'm
 reviewing my configurations and documenting them. I've managed to run
 across a few issues where configurations I plucked off the Internet are
 working but don't seem to be valid. At least I can not find any
 documentation for the options I set.  Is it stale documentation?
  Deprecated options?  Just plain wrong examples?  With a configuration file
 like XML which is designed to ignore options it doesn't understand, this is
 even more frustrating.  With rapidly  changing feature sets it's maddening.


Sometimes the people implementing things can't see things from a fresh
perspective - they can't unlearn what they already know.

That is why we rely on the community to provide patches - even to
documentation - to help clarify things.
It's a great place to start if you want to get involved - it's where I
started.

We also need people withe skills and desire to improve documentation.
Technical writing and cutting code are orthogonal skills that rarely sit in
one individual.
So if you have someone on your team who can write technical docs then
convince them, your management, etc that it benefits your team to help
improve these docs and give back to the project. It will also help future
projects at your org.

Actually having access to OLD documentation would help understand the
 difference between the old but still supported vs. the shiny, new
 preferred way.


The previous plugin docs are always available they are versioned on the
website.
But they are unlikely to discuss why things were changed.
You might get lucky and find that information in the jira changeset.


 I still have not found a good discussion about the difference between
 using the POM reporting section and adding reporting plugins to the
 maven-site-plugin in the build section. All I know at the moment is more
 plugins seemed to work as I expected when adding the plugins to the
 maven-site-plugin in the build section than when trying to add them to the
 reporting section.


That discussion is in the mail archives, but you would have to hunt for it.
If you are using maven 3 then the reporting section no longer works.


 For whatever reason, my career has been one of trouble shooting, proof of
 concept and other, very targeted activities.  I almost never do the same
 job or use the same technologies for more than a year or two.  My efforts
 historically rely on being clever, persistent and willing to buy every book
 I can find on the subject. Generally, the modern JavaDoc mentality of
 documentation blows.  If I want to read the source code (and I can) I'll
 write the source code (which I can).  If I have to dig in that deep to
 figure your plugin out, it's not really saving me much time is it?


You've described my job too.
I tend to write things up not for others but for myself in the future.
I've been surprised more than once to google a problem only to find that I
answered that myself a while ago...

Re: Complex Maven projects - Tutorials? Books?

[Barrie Treloar]

On 13 June 2014 00:16, Hohl, Gerrit g.h...@aurenz.de wrote:

 We use Maven and Jenkins for about 1.5 years now, I guess. Until now the
 Maven projects have been very simple and - let's say - very monolithic.

 But recently we identify more and more internal libraries in our
 products. Of course we don't want to share this libraries by
 copy-n-paste between the products - especially as we have Maven.

 So we started to read books, tutorials on the Internet and so on. But


Can you list what you've read so far?
I assume you've gone through the ones we link at the Maven site?
http://maven.apache.org/articles.html


 most of them only deal with simple projects. They don't cover e.g.
 versioning the build process (especially if your build process consists
 of more than just one step). They also don't cover the problems of
 developing the libraries while your developing the products which depend
 on them. Especially at the beginning your libraries will go through a
 lot of changes. A few name snapshots as a solution, but don't explain
 how you can work using them, how you can use them in your pom.xml and
 how you deal with them if you finally switch your product and/or your
 library from the snapshot state to the release state. A few also say
 that you shouldn't use snapshots at all because it will result in many
 problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds
 or build triggered by the SCM are also an issue here.


I highly recommend that you sit down locally with your group and write up a
list of questions, and then document them on your internal wiki.
Work through which ones are causing you the most pain (whatever that may
be; confusion, build stability, slow build times, etc)
And after you've done some googling, searched the archives, etc, then come
back and ask the questions individually here.

A lot of the problem you will find when you get to this level is that it's
hard to express the concepts if you haven't already been exposed to them
before.
And we can't give the advice you want because we have to both upskill and
explain options and their alternatives.

Look for blogs by active members of the community, some that come to mind
are (in no particular order):
  * Brian Fox - http://blog.sonatype.com/author/brian/
  * Stephen Connolly - http://javaadventure.blogspot.com.au/
  * Ron Wheeler - http://blog.artifact-software.com/tech/?author=2

And when you think you've found the answers - contribute them back to the
community.

Re: Complex Maven projects - Tutorials? Books?

[Barrie Treloar]

On 13 June 2014 09:07, mike digioia mpd...@gmail.com wrote:

 So how does this book help you any more than all the detailed online Maven
 docs that exists and are updated?


It's just another source of information.

The docs don't really walk you through everything, they are mostly focused
on a particular plugin and not on how to pull all this together.

Re: Problem with maven

[Barrie Treloar]

On 4 June 2014 00:12, amit dhanani amit.dhan...@yahoo.com.invalid wrote:

 Dear Sir,

 I have installed maven 3. In jenkins it shows error while building.


Did you try building this from the command line?
You need to make sure you use the same command line that jenkins is doing
or you will have environmental issues to deal with too.
It may also help to purge your local ~/.m2/repo cache to mirror having a
clean environment.

[del]

[workspace] $ /usr/share/maven3/bin/mvn clean install -o


[del]


 [ERROR] Plugin org.easyb:maven-easyb-plugin:1.4 or one of its dependencies
 could not be resolved: Cannot access central (
 http://repo.maven.apache.org/maven2) in offline mode and the artifact
 org.easyb:maven-easyb-plugin:jar:1.4 has not been downloaded from it before.


Did you read the error message?
Your maven invocation is using the -o option.
mvn --help
will show you that -o means --offline Work offline

The error message shows that you have not downloaded this plugin before and
because you are offline it will not download it for you.
Maven can't work when it is missing stuff.

Re: M2Eclipse vs. maven-eclipse-plugin: which is preferred?

[Barrie Treloar]

On 9 May 2014 18:49, Thomas Broyer t.bro...@gmail.com wrote:

 Hi all,

 Does the Apache Maven Project/Community has an official stance about
 whether M2Eclipse or maven-eclipse-plugin is preferred way of importing
 Maven projects into Eclipse?

 I thought M2Eclipse was the blessed way, but I cannot find anything
 official online.
 Only that the maven-eclipse-plugin hasn't been updated for a while, but
 that could also be a sign that it has no issue and Eclipse offers backwards
 compatibility.

 Note: this is not a poll about what you as a developer prefers, I'm looking
 for whether there's an official position and which one it is.
 Background: I'm in a argument in a code review for an archetype about
 whether to include maven-eclipse-plugin configuration within the POM or
 not; and any official choice would help us avoid bikeshedding.


There isn't anything really official.

The maven-eclipse-plugin doesn't get much love any more these days, but
still works fine for some people.

However you will probably find the m2eclipse experience better.

Other alternatives to consider are other editors.
I've never used NetBeans or IntelliJ but others report good experiences.

Re: use separate mirrors for project dendencies and plugin dependencies ??

[Barrie Treloar]

On 6 May 2014 20:23, Anders Hammar and...@hammar.net wrote:

 
  Presumably you are trying to separate artifacts used by plugins during
  your build (where you might use e.g. GPL licensed modules) from artifacts
  used as dependencies in your project proper (where using that same GPL
  licensed modules would make your legal department scream) by separating
 the
  repositories used to provide them.
 
  As far as I know/understand all artifacts are downloaded to the same
 local
  cache repository (~/.m2/repository), regardless of whether they were
  required by some plugin or as a dependency of your project.
 
  This makes them available for both purposes and thus obliterates all your
  efforts of keeping them separate.
 
  Maven Masters: Please correct me if I'm wrong.
 

 I don't think this is correct with Maven 3. Maven 3 uses Aether which AFAIK
 keeps the repository id for the artifact to verify from where it was
 downloaded. Haven't verified for this use case though.

 So, using Maven 3 it should be possible to specify one repository
 declaration for your deps and one pluginRepository declaration (with a
 different repo id) for your plugins (incl deps). If you msut use mirror
 declarations, I would use this for the deps and add exclusions (using '!')
 for any pluginRepository.

 /Anders


I don't remember what happens for duplicates.
I think it used to complain that the artifact doesn't exist (if the one it
downloaded from is not available, even though its available elsewhere).

The GPL example isn't a good one, as the output of running GPL is not GPL
itself.

I think Nexus allows you to restrict things by licence so that you can
curate what is available in your repository manager. You'd have to look at
the docs to find out.

Re: use separate mirrors for project dendencies and plugin dependencies ??

[Barrie Treloar]

On 6 May 2014 09:21, Dan Tran dant...@gmail.com wrote:

 for legal purpose ( btw, please dont drill me here), I would like to use
 one mirror as a gate way for all of of my project dependencies,and another
 mirror as a gate way for all of my plugins and their dependencies


 is it possible? Posting a settings.xml config here is very much appreciated


Having not done this, here is some more insane advice.

I'd use three.
One proxy to proxy the other two proxies.
All developers point to the master proxy.
You can then configure the master proxy to refer to the project
dependencies proxy and another for plugins dependencies proxy.

You might need a more sophisticated maven repository manager that you can
restrict what is allowed in the proxies (i.e. it just doesn't go and grab
stuff for you).

You're going to have to do a lot of fiddling to get this to work.
I'm not convinced it is going to give you what legal thinks it will...

If you could write up what you tried and whether it worked it would be
helpful for anyone else attempting the same thing...

Re: Netbeans maven project with invalid POM/classpath problem

[Barrie Treloar]

On 1 May 2014 06:48, Mark mark@gmail.com wrote:

 Browsing the local Maven repository using Netbeans I find the following
  if I right-click on the ojdbc 11.2.0 jar and select 'View Details'

 --
 org.apache.maven.project.InvalidProjectModelException: 1 problem was
 encountered while building the effective model
 [FATAL] Non-parseable POM C:\Users\mcedward\.m2\
 repository\com\oracle\ojdbc6\11.2.0\ojdbc6-11.2.0.pom: end tag name
 /body must be the same as start tag meta from line 142 (position: TEXT
 seen ...!-- End of carousel script --\n/body... @453:8)  @ line 453,
 column 8  for project  for project
 at org.apache.maven.project.DefaultMavenProjectBuilder.
 transformError(DefaultMavenProjectBuilder.java:193)
 at org.apache.maven.project.DefaultMavenProjectBuilder.
 buildFromRepository(DefaultMavenProjectBuilder.java:240)
 at org.apache.maven.project.DefaultMavenProjectBuilder.
 buildFromRepository(DefaultMavenProjectBuilder.java:251)
 at org.apache.maven.project.DefaultMavenProjectBuilder.
 buildFromRepository(DefaultMavenProjectBuilder.java:258)
 at org.netbeans.modules.maven.repository.ui.
 ArtifactMultiViewFactory.readMavenProject(ArtifactMultiViewFactory.java:
 231)
 at org.netbeans.modules.maven.repository.ui.
 ArtifactMultiViewFactory.access$000(ArtifactMultiViewFactory.java:104)
 at org.netbeans.modules.maven.repository.ui.
 ArtifactMultiViewFactory$1.run(ArtifactMultiViewFactory.java:187)
 at org.openide.util.RequestProcessor$Task.run(
 RequestProcessor.java:1423)
 at
 org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)


Have you opened that file in a text editor?
It looks like malformed xml to me.

How did you install the ojdbc jars?
These need to be manually installed since they require you to agree to the OTN
License Agreement.

Re: Help with converting existing ant build to maven is required - forking

[Barrie Treloar]

On 30 April 2014 11:54, Maxim Solodovnik solomax...@gmail.com wrote:

 Here is the structure:

 Openmeetings Util project has compile time dependency Red5 server
 Almost all other projects are dependent on Openmeetings Util and Red5
 server (compile time)

 But When I'm creating war file in Openmeetings Web project I need to
 remove Red5 server and all it dependencies from the WEB-INF/lib folder
 since all these jar files will be placed into tomcat/lib folder.


I highly recommend having a look at the freely available books at
http://maven.apache.org/articles.html

You might not need that knowledge right now, but you will eventually, and
it may also trigger off more thoughts about what else you would like to
achieve with the conversion.

Re: Generating war and Jar from same codebase

[Barrie Treloar]

On 23 April 2014 13:45, Narayanan K knarayana...@gmail.com wrote:

 Hi Anders

 The codebase is the same. So having 2 separate directories (for
 modules) and pom in each of them is not required right ?

 I can have modules in parent pom to specify the 2 child poms that
 are present in the same project level. Tried below and seems it is
 working.

 parent pom will have :

 modules
   modulepom-war.xml/module
   modulepom-jar.xml/module
 modules


Please have a look at the freely available books at
http://maven.apache.org/articles.html

Spending a few hours reading about how things should be done and the
concepts behind them will be your best use of time.
This will help boost your knowledge and help you to articulate your
questions to get the best answers in the future.

Re: Forcing Integration Tests Before a Release

[Barrie Treloar]

On 26 March 2014 07:34, Eric Kolotyluk eric.koloty...@gmail.com wrote:

 I have tried to get this working, but it does not seem to work. When I do

   mvn release:prepare

 I get

   [INFO] Executing: cmd.exe /X /C D:\bin\Apache\apache-maven-3.1.1\bin\mvn
 -s C:\Users\Eric\AppData\Local\Temp\release-settings2652114304406041143.xml
 clean verify site --no-plugin-updates -Psonatype-oss-release -P
 user,local-repository

 In the output I can see the 'clean' and the 'site' happen, but the
 failsafe integration tests do not run. If I do

   mvn verify -P run-it

 then the integration tests run as normal.


What is -X telling you?
Is the variable performRelease actually set?

Looking at org.apache:apache:10 the release-plugin is configured different
to the docs.
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-release-plugin/artifactId
  version2.1/version
  configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
arguments-Papache-release/arguments
  /configuration
/plugin

i.e. it disables useReleaseProfile and forces the apache-release profile to
be used.

I've had a quick look at the code, and I dont think this variable will be
set on prepare.
The performRelease variable looks like it is only set on perform not
prepare.
http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile

You can use
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#argumentsto
provide additional arguments to the release plugin.
The code in AbstractReleaseMojo.createReleaseDescriptor() builds a list of
active profiles and so you can just configure the release plugin to include
-P run-its (which is the profile name used in
org.apache.maven.plugins:maven-plugins:22 so I assume its the preferred
name)

Since it is the same plugin, I dont think you are going to be able to
separate out running the integration tests only in prepare.
They are going to be run again in perform.
This is probably not a bad thing.

Re: Forcing Integration Tests Before a Release

[Barrie Treloar]

On 21 March 2014 06:02, Eric Kolotyluk eric.koloty...@gmail.com wrote:

 I am looking for some way to force my integration tests before a release,
 without explicitly using a profile.

 [del]



 Is there some way I can trigger the integration tests when doing a release

mvn release:prepare

 without having to do

mvn release:prepare -P run-it


Have a look at the apache parent pom chain.

There is some activation stuff in there that gets run when you do a release
- I can't recall how it does it.
e.g. always generating source jars

Re: how to only build if version is changed..

[Barrie Treloar]

On 14 March 2014 23:16, richard_senior richard.sen...@gmail.com wrote:

 Hello,

 We are using maven, jenkins and nexus for continuous integration.

 Our trunk branch contains no snapshots, and jenkins is polling the scm and
 building on any change.
 However periodically a developer may check things in without upversioning
 the pom.
 When they do this the build fails at deploy as nexus will not allow to full
 release versions with the same number.
 Which is obviously good... But I would like to fail the build early, before
 deploy, so that when a developer tries to build
 the project in their local workspace, they can see that they must change
 the
 version number.

 How would I add a goal to maven that failed, if nexus contains a binary of
 the project I'm building, at the same version as the pom?

 I'm guessing I'd need to use the enforcer, and perhaps the maven versions
 mojo, but I don't know the exact config?


Why aren't you using snapshots?
This is exactly what they are used for.

Re: Need Help

[Barrie Treloar]

On 15 March 2014 07:40, Mirko Friedenhagen mfriedenha...@gmail.com wrote:

 Hello,

 I had the same questions :-).

 Vishai, you could invoke mvn compile, switch to the target/classes
 directory and execute time jar cvf ../foo.jar . to see how long the
 original jar command takes and compare this to the time needed by the
 maven-jar-plugin.


mvn -X also gives some times but you need to do the math yourself.

Re: Using github as a maven repo

[Barrie Treloar]

I've updated the stackoverflow question
http://stackoverflow.com/questions/14013644/hosting-a-maven-repository-on-github
with these answers.
http://stackoverflow.com/a/22210816/552958

And spammed the best hits on google for similar questions.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven copies 3 jars in lib folder (skinny war) for no reason

[Barrie Treloar]

On 28 February 2014 20:33, poroto20 porot...@gmail.com wrote:
 I have one EAR project and I am trying to have a skinny war. It seems to be
 working ok but for some reason it keeps copying 3 dependencies into war/lib
 folder, which are commons-logging-1.0.4.jar, commons-codec-1.4.jar and
 jboss-seam-2.2.1.Final.jar.

 I the EAR's pom I added `skinnyWarstrue/skinnyWars`. I made sure I added
 exclusions for those three jars, or they are `scope=provided`. I also added
 `packagingExcludes**/*.jar/packagingExcludes` in the WAR's pom file.

 I really can't understand maven's logic to create the war (or to copy those
 jars).

Run with -X
You get oodles of feedback.
Make sure you redirect this output to a file for investigation.

Maven should tell you what gets included and where from and you can
investigate from there.
You will probably need to add an exclusion to the offending artifact.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Findbugs doesn't check unit tests

[Barrie Treloar]

On 27 February 2014 09:05, Eric Kolotyluk eric.koloty...@gmail.com wrote:
 I added the following to my POM

   reporting
 plugins
   plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdfindbugs-maven-plugin/artifactId
 version2.5.3/version
 configuration
   effortMax/effort
   thresholdLow/threshold
 /configuration
   /plugin
 /plugins
   /reporting

 And it works great for my main source, but it does not seem to check my test
 source. It seems to me it would be useful to run findbugs on test code too.
 Is there some simple way to configure this?

I dont use FindBugs.

But Umm, is this what you want?
http://mojo.codehaus.org/findbugs-maven-plugin/check-mojo.html#includeTests

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why does Maven fail to compile my project occasionally?

[Barrie Treloar]

 Well, Eclipse is not installed on my daily-build server, so I guess it has
 nothing to do with Eclipse. ;-)

 I guess when Maven encounters the missing-dependency compilation error, it
 doesn't stop compiling immediately, and it tries its best to compile other
 unrelated modules. When I compile the whole project again, the missing
 dependent modules may appear in the local repository because the unrelated
 modules compiled previously have declared them as dependencies.

 Anyway, the long-lasting problem has been solved perfectly. Thank you guys!

What you have is a http://en.wikipedia.org/wiki/Heisenbug
And you need to understand what the root cause of the problem is.
Otherwise you will suffer this problem again in the future.

Plus, once you understand the problem you should post back to the list
and explain it.
So that other people can google their similar problems and find the answer.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Where the binnary of mvn knows which mojo do i want to execute?

[Barrie Treloar]

On 25 February 2014 00:46, enrique bernal ruiz kbernalr...@gmail.com wrote:
 Hello! And thank you so much for your help.
 I am working(starting) with it, and i am trying to understand it. What mvn
 does when i call mvn run for example, i mean, I have a collection of mvn


Please have a look at the freely available books at
http://maven.apache.org/articles.html

Some of these may be in a language more native to you than English.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: OutOfMemory exception when using Maven in ant

[Barrie Treloar]

 I am trying to incorporate Maven dependency management into my ant build as 
 follows:
[del]
 java.lang.OutOfMemoryError: PermGen space


This is a Java problem rather than a Maven or Ant one.
It has to do with not enough memory to load all the classes into the
PermGen space.
You can read up about PermGen space to get more of an idea as well
* http://www.oracle.com/technetwork/java/javase/memleaks-137499.html#gbyuu
* http://java.dzone.com/articles/busting-permgen-myths

See 
http://stackoverflow.com/questions/88235/dealing-with-java-lang-outofmemoryerror-permgen-space-error
for some solutions.

It talks about Tomcat, but the problem occurs in command line Java.
As a workaround use (or large values than 128M if needed)
-XX:MaxPermSize=128M

Also look at similar XX options at
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: OutOfMemory exception when using Maven in ant

[Barrie Treloar]

On 19 February 2014 13:07, Ron Bets ron.b...@oracle.com wrote:
 Thanks for the speedy response.

 I have run across these types of memory exceptions in the past, but given 
 that the build had been working correctly until I added the Maven 
 artifact:dependencies/ bit, I naturally jumped to the conclusion that there 
 was something odd going on.  This was exacerbated when the ant error log 
 actually identified the artifact:dependencies/ as the offending line in the 
 build file.  I'll play around with the memory parameters and see what happens.

 Cheers,
 Ron

 Btw, is there a reference for all parameters supported by 
 artifact:dependencies/?  I have

You mean this one?
http://maven.apache.org/ant-tasks/examples/dependencies.html


I'm afraid the two people who have answered your question really dont
use Ant, so we dont know much about what you are doing.
We use Maven natively rather than Ant with Maven dependency stuff.

I'd recommend looking at the freely available books at
http://maven.apache.org/articles.html and seeing whether you want to
take the full plunge and migrate to Maven completely.
Ant has its place, but for managing the Java software development
lifecycle I'm obviously biased towards Maven :)

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter

[Barrie Treloar]

On 13 February 2014 23:25, Ron Wheeler rwhee...@artifact-software.com wrote:
 Good point.
 After I fixed the spelling, it works fine.

 Is was a great help to have a second set of eyes to find my stupid mistakes.

 It would have been nice to have a better error message.


 [WARNING] The following patterns were never triggered in this artifact
 inclusion filter:
 o  'com.artifact-software.taw:taw-localized-iumessage-ws:war'
 o  'com.artifact-software.taw:taw-dataccess-ws:war'

 A file not found would have been more helpful.
 I tested to see if the file was not found by adding a deliberate spelling
 mistake but I drew the wrong conclusion when I got the same error message.

You're welcome to make a patch :)

I dont think it is working with files at the point it is doing all the
checking, especially if the filter has a * in it.

I guess you could use
http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29

And if they are close include a Did you mean this instead?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter

[Barrie Treloar]

 From
 http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
 I think the shortened form assumes a jar classifier.
 I'm guessing from your assembly name webapps-tar.xml that these might be
 wars?
 Have you tried using the long form of the dependency conflict id?

 I am not sure what you mean by this.
 The dependency specification in the pom has the right type.
 I tried adding the version and type in the assembly file and just got an
 error message with a more specific file name.

http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
defines the spec for dependency conflict id and it does not include
version.

It is either
* short form = groupId:artifactId
* long form = groupId:artifactId:type:classifier

Can you paste in your pom values for the dependency, as well as the
snippet from your assembly file.

I'm suggesting that you may not be able to use
includecom.artifact-software.taw:taw-localized-iumessage-ws/include
but instead need
includecom.artifact-software.taw:taw-localized-iumessage-ws:war:/include

 I have not specified a specific phase but I assume that the plug-in is being
 triggered since the error comes from the plug-in.

 I did read the docs but there is no example showing including of specific
 dependencies.

http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
Has the example you want to look at.
It has the assembly descriptior, the pom that describes the plugin
management, and the actual pom that defines the dependencies and
invokes the assembly plugin.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why is dependency:analyze lying to me?

[Barrie Treloar]

On 13 February 2014 00:20, Mark H. Wood mw...@iupui.edu wrote:
 On Wed, Feb 12, 2014 at 08:11:29AM +1030, Barrie Treloar wrote:
 [snip]
 I think Maven is missing a scope, it needs to break up test into two
 phases; testCompile and testRuntime instead of having one scope which
 means both.
[del]
 Picky terminology tweak:

Yes, my bad.
I meant break that one scope into two scopes (not phases).
Much like there are two scopes for compilation (compile and runtime),
there needs to be two scopes for test (compile and runtime).

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Adding dependency management to parent pom causes errors

[Barrie Treloar]

On 12 February 2014 20:12, Adrien Rivard adrien.riv...@gmail.com wrote:
 Hi,

 DependencyManagement is declaring dependencies(mostly for versions) and
 dependencies is using them,
 So in general you should have only dependencyManagement in the parent poms
 and only dependencies in the childs.

 Now there are exceptions, for example junit is generally used in all child
 projects , so you can add it in dependencies of the parent pom and it will
 be avaible in all childs.

Adding dependencies into the pom with modules is a bad idea,
There will always be an exception that breaks that rule.
Then you will be asking how do I remove a dependency from a child pom
- you can't, dont define it in the first place.

Typical exceptions would be poms whose sole purpose is to build an
assembly (zip file) for package management, or Ear poms, etc.

A best practice is to never have any dependencies in a pom that has modules.
If you want to share common dependencies between projects, then you
can look at using the inherit type relationship but that pom would be
a standalone pom with no module declarations.
Your top level project is an Aggregation pom to make running Maven easier.
See https://maven.apache.org/pom.html#Aggregation

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter

[Barrie Treloar]

On 13 February 2014 02:24, Ron Wheeler rwhee...@artifact-software.com wrote:
 I did a debug run and I think that the log shows where the includes get
 idwebapps/id
formats
   formattar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
 dependencySet
   outputDirectory/target/outputDirectory
   useProjectArtifactfalse/useProjectArtifact
   unpackfalse/unpack
   scoperuntime/scope
   includes

 includecom.artifact-software.taw:taw-localized-iumessage-ws:war/include
 includecom.artifact-software.taw:taw-dataccess-ws:war/include
   /includes
 /dependencySet
   /dependencySets
[del]
 [DEBUG] com.artifact_software.taw:taw-localized-uimessage-ws:war:1.0.2 was 
 removed by one or more filters.
 [DEBUG] com.artifact_software.taw:taw-dataaccess-ws:war:1.0.2 was removed by 
 one or more filters.

 [WARNING] The following patterns were never triggered in this artifact
 inclusion filter:
 o  'com.artifact-software.taw:taw-localized-iumessage-ws:war'
 o  'com.artifact-software.taw:taw-dataccess-ws:war'
[del]
 http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
 defines the spec for dependency conflict id and it does not include
 version.

 It is either
 * short form = groupId:artifactId
 * long form = groupId:artifactId:type:classifier

I'm guiding you blind since I've not done this before.
The output is telling us that the pattern
'com.artifact-software.taw:taw-localized-iumessage-ws:war'
does not match the artifact
com.artifact_software.taw:taw-localized-uimessage-ws:war:1.0.2

And there is your problem.
You have an _ in your groupid for the artifact, but not your include filter.

I've been looking at maven-common-artifact-filters-1.4
PatternIncludesArtifactFilter.matchAgainst(). since I thought that may
you needed a trailing : on the long id.

But it does the right thing with as much of the pattern you provide
- and wildcards the rest.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why is dependency:analyze lying to me?

[Barrie Treloar]

On 12 February 2014 07:41, laredotornado-3 laredotorn...@gmail.com wrote:
 Hi,

 I'm using Maven 3.1.1 on Mac 10.9.1.  When I ran mvn dependency:analyze on
 my project, I got results that included:

 [WARNING] Unused declared dependencies found:
 ...
 [WARNING]junit:junit:jar:4.11:test

 So I commented out the above junit dependency in my pom (declared like so):
[del]
 java.lang.NoSuchFieldError: NULL
 at org.junit.runners.ParentRunner.init(ParentRunner.java:48)
 at
 org.junit.runners.BlockJUnit4ClassRunner.init(BlockJUnit4ClassRunner.java:58)
 at
 org.springframework.test.context.junit4.SpringJUnit4ClassRunner.init(SpringJUnit4ClassRunner.java:104)

 This isn't the only dependency that the analyze goal lists that wreaks havoc
 when I comment it out.  Is there another way to detect what dependencies are
 truly not needed by my project?

Unfortunately this stuff is not documented well enough in the plugin.
You're welcome to submit a patch!

Have a look at 
http://maven.apache.org/plugins/maven-dependency-plugin/faq.html#unused

I think Maven is missing a scope, it needs to break up test into two
phases; testCompile and testRuntime instead of having one scope which
means both.
This means that the analyze code can't tell what stuff is needed for
tests at compile time and what is needed at runtime.

If my memory serves me right, that would mean for your example that
Spring is a compile time dependency but junit would be a runtime
dependency.
Hence the incorrect Unused declared dependencies found error.

I would manually ignore anything found in the test scope from the error list.
I never found the time to go hacking the plugin to work better - i.e.
if it is test scope it really can't tell the difference between unused
dependencies and shouldn't report them.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Adding dependency management to parent pom causes errors

[Barrie Treloar]

On 12 February 2014 10:17, Laird Nelson ljnel...@gmail.com wrote:
 First, and foremost, it is template information.  If a given real
 dependency somewhere else omits a piece of information, then that piece
 of information is taken (if possible) from the dependencyManagement
 section.

This is also best practice.

Appliying DRY principles you pull up all the dependency information
from your child poms into your parent pom's dependencyManagement
section.
Then in your child poms you *always* omit the version information in
your dependency section.

This way you know that your project is using a consistent version of artifacts.
The last thing you want is for your project to be using a mish-mash of
GWT versions (1.0 in one project, 2.6 in another, etc).

This gives you one place to define the versions.
And when its time to upgrade then one place to make the change.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Adding dependency management to parent pom causes errors

[Barrie Treloar]

On 12 February 2014 11:51, Laird Nelson ljnel...@gmail.com wrote:
 Agreed wholesale.  I think the original poster was wondering why this
 stanza:
[del]

You did a good job there so I didn't add any value to the response.

 While we're on the subject of best practices in this area, we've also found
 that dependency managing the versions of even child modules pays off in
 the end.

Be careful here.
People get confused with what a module is.

A module is not a dependency.
I think of it as a handy shortcut to allow me to run a maven command
at the top and have the same command also run in any module
declaration.
Logically a module is a group of things that tend to get released
together. If that is not the case, then don't use a module.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-assembly-plugin:2.4 The following patterns were never triggered in this artifact inclusion filter

[Barrie Treloar]

On 12 February 2014 11:43, Ron Wheeler rwhee...@artifact-software.com wrote:
 I am trying to build a timesaving module that will build tar files to be
 installed on a server
 I have defined a bunch of dependencies in the pom and want to build 2 tar
 files by invoking 2 instances of the plug-in.
 In each one I want to specify a list of dependencies to be included from the
 repository.
   in the assembly descriptor I have
   dependencySets
 dependencySet
   includes
 include com.artifact-software.taw:taw-localized-iumessage-ws
 include com.artifact-software.taw:taw-dataccess-ws:

 I would like it to take just these 2 modules for this tar file.
 There are a lot more dependencies that will go in the second invocation of
 the assembly plug-in.


 This gets the following message

 [INFO] --- maven-assembly-plugin:2.4:single (default) @
 taw-webapps-assembler ---
 [INFO] Reading assembly descriptor: src/assembly/webapps-tar.xml
 [WARNING] The following patterns were never triggered in this artifact
 inclusion filter:
 o  'com.artifact-software.taw:taw-localized-iumessage-ws'
 o  'com.artifact-software.taw:taw-dataccess-ws:'

 [INFO]
 
 [INFO] BUILD FAILURE
 [INFO]
 
 [INFO] Total time: 9.658s
 [INFO] Finished at: Tue Feb 11 19:54:13 EST 2014
 [INFO] Final Memory: 10M/148M
 [INFO]
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-assembly-plugin:2.4:single (default) on
 project taw-webapps-assembler: Failed to create
 assembly: Error creating assembly archive webapps: You must set at least one
 file. - [Help 1]

 What have I misunderstood about the assembly.

I'm assuming you've read the docs.

From 
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
I think the shortened form assumes a jar classifier.
I'm guessing from your assembly name webapps-tar.xml that these might be wars?
Have you tried using the long form of the dependency conflict id?

From 
http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
What phase to did you attach the plugin to?
It may be possible you haven't bound it to a phase that has resolved
the dependencies and so there are none for it to find.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't Find Scala Archetype

[Barrie Treloar]

On 12 February 2014 13:14, Eric Kolotyluk eric.koloty...@gmail.com wrote:
 I am using the Typesafe Eclipse IDE, and for some reason it cannot find the
 archetype for

 groupIdnet.alchim31.maven/groupId
 artifactIdscala-archetype-simple/artifactId
 version1.5/version

 At one time it could, but now it can't, and I have no idea why. The
 diagnostics are completely useless in understanding the problem.

 Can anyone suggest anything that might be wrong and how to fix it?

Central says it exists
http://search.maven.org/#search|ga|1|scala-archetype-simple

Are you behind a proxy?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven 3.1.1. and Windows 8

[Barrie Treloar]

On 29 January 2014 08:26, Manuel Mastrofini
manuel.mastrof...@infoone.it wrote:
 Thank you for your contribution.

 The failing line is:

 .shared.domain.C:\Program Files (x86)\Java\jdk1.7.0_45\bin\java.exe
  -classpath
 D:\apache-maven-3.1.1\bin\..\boot\plexus-classworlds-2.5.1.jar
 -Dclassworlds.conf=D:\apache-maven-3.1.1\bin\..\bin\m2.conf
 -Dmaven.home=D:\apache-maven-3.1.1\bin\..
 org.codehaus.plexus.classworlds.launcher.Launcher -v

 It is immediately after .shared.domain.set
 CLASSWORLDS_LAUNCHER=org.codehaus.plexus.classworlds.launcher.Launcher

 Manuel

Manuel, it is very difficult to help you trouble shoot because you are
not providing enough information.
Wayne has tried to coax this information out of you but you have not
answered all his questions, and when you do you will need to paste in
the results from the computer rather than paraphrasing as we need the
actual error messages/debug information to learn more.

Have a look at http://www.catb.org/~esr/faqs/smart-questions.html in
general, and specifically the Be precise and informative about your
problem section.

Go through the emails again and make sure you have answered Wayne's
questions and provided enough details in the answers and we will
probably have more luck in helping you out.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to mkdir and move files as part of build

[Barrie Treloar]

On 15 January 2014 23:16, Don'tTellMeToGoogleItDammit c...@rmen.ca wrote:
 I Googled this, and came to this forum, only to find a remark telling me I
 should have Googled this.

 Always annoying to find this remark.

Not knowing what you are attempting to do (because you were too busy
flame-baiting to bother to tell us) and dreading up zombie threads - I
assume you actually clicked on the links in this thread?
e.g. http://tinyurl.com/62f6ku

I'm assuming you want to mkdir and move files as part of the build.
Which the ant plugin will do for you.

Otherwise, please have a look at the freely available books at
http://maven.apache.org/articles.html they might help you with your
problems too.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

[Barrie Treloar]

On 15 January 2014 01:40, KARR, DAVID dk0...@att.com wrote:
 Again, I didn't want to debate whether this is convenient, I just wanted to 
 know if Maven dependency resolution and things like the EAR plugin will have 
 any trouble incorporating multiple dependencies with the same G:A, but 
 different version.

David, you've been on the list long enough to see the term If you
fight Maven you will lose.
That way pain lies.

You will have much more joy solving the problem in a way that Maven helps you.

Does any of Stephen's response help out?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Running cleanup code after tests in multi-module project.

[Barrie Treloar]

On 14 January 2014 10:49, Todd Chapman t...@chaka.net wrote:
 Anders,

 I agree with you. Unfortunately I inherited this project and there is setup
 required that is identical for each module and is expensive to set up and
 tear down. It will take time to refactor the tests to be less expensive to
 prepare.

 In the mean time I'm looking for ways to deal with situation I have now.

It sounds like these tests are not unit tests if they need any
setup/teardown of external systems.
These are integration tests.

It would make more sense to move these tests into one integration-test module.
You then get your one setup/teardown and all the tests are together.

It should be a matter of moving things around in version control
rather than having to refactor the tests.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

[Barrie Treloar]

On 14 January 2014 10:54, KARR, DAVID dk0...@att.com wrote:
 I have a situation where it would be convenient for my pom to have two 
 dependencies that are almost identical, only being different by the version.  
 The makeup of the artifact is such that it would be safe (and intended) to 
 use both of them.  The Java package used in each is similar, but different.  
 The package will vary along with the version number.

 Will dependency resolution and the EAR plugin (and any other mechanism that 
 lists dependencies) have any trouble with this?

Can you describe why you think this would be convenient?
Have you looked at classifiers?
http://stackoverflow.com/questions/8040964/how-to-use-or-abuse-artifact-classifiers-in-maven

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven install phase - Access is denied

[Barrie Treloar]

On 9 January 2014 06:56, andre999 andre...@hotmail.com wrote:
 build
[del]
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-install-plugin/artifactId
 version2.5.1/version
 configuration
 filecertloader-custom-action.jar/file
 
 filecertloader-custom-action-sources.jar/file

What do you expect this section to do?
http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html
does not have a file property.
And file implies a single entry, specifying it a second time would
mean you overwrite the previous value.
Lists are normally plural. (something like
filesfileA/filefileB/file/files

If you want the sources to also be installed use the source plugin
http://maven.apache.org/plugins/maven-source-plugin/

You shouldn't need this section on install at all.

I can't see anything in that pom that would mean a directory is being
installed into your local m2 cache.

The assembly plugin can have these types of issues when you specify
dir as a distribution format on deploy.
But deploy is after install so this is not the problem.

The problem I have is that it is trying to install
P:\Projects\HlkProjects\CertLoader\hlk-certloader\trunk\target\install4j\certImport
to
P:\.m2\repository\net\healthlink\certloader\hlk-certloader\1.0.2-SNAPSHOT\lk-certloader-1.0.2-SNAPSHOT-certImport

Why is maven attaching \target\install4j\certImport as a build
artifact that it thinks it needs to install.

Try running mvn -X and redirect the output to a file.
Then search for target\install4j\certImport and see which plugin is
being configured with this value.
That might give you a hint as to where to look to turn that off.
I'd almost suspect the parent pom.
Using resources:copy-resource does not attach anything to be installed
and it is the only thing that is using target\install4j\certImport
from your supplied output.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: DefaultProjectBuilder ... mavenTools: null [Was: Re: Programmatically get maven properties]

[Barrie Treloar]

On 8 January 2014 09:00, juliangeo julianhernand...@gmail.com wrote:
 Hi!

 I'm new to Maven and I've been struggling with this for a while. I just need
 to be able to programmatically build a project from a pom file in order to
 retrieve its relevant information. I am not using, nor want to, a maven
 plugin, just need this functionality as part of my application.

 I've tried the code you successfully got to work but no luck so far. I still
 get the mavenTools: null from the repositoryManager being null. Am I
 missing something? Should I run this on some kind of special environment?

 I'd appreciate any help as I'm really lost here.
[del]
 I'd be surprised if that worked.

 Maven makes heavy use of dependency injection via Plexus and chances
 are you haven't set up some component that is being used.

Your answer is already here.

You just can't use the classes outside of the Maven environment
without also setting up all the other dependencies that are needed by
that class.
And as noted, this is done by Dependency Injection (via Plexus).
You will need to look at MavenArtifactRepository and see what other
objects need to be instantiated and set into it for it to work
properly.

Your use case is not something others are really trying to do, so you
are unlikely to find someone with the knowledge to help.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier

[Barrie Treloar]

On 7 January 2014 09:42, erich8 eric.herrm...@intermedix.com wrote:
 Barrie Treloar wrote
 When you build Product X the libraries A, B and C should already
 exist.  You dont want to rebuild them just to build Product X, that
 will slow down your development process.
 Ideally A, B, and C are released versions, but if you find a bug in
 them then you will be using SNAPSHOT versions, which will need to be
 released separately prior to releasing Product X.
 If developers are rarely touching the libraries then its better to let
 your continuous build system (e.g. Jenkins) build the libraries and
 Maven will automatically pull down the latest SNAPSHOT for you.
 This way Developer D can fix a bug in A and Developer E will
 automatically get the bug fix the next time they pull down the
 SNAPSHOT build of library A, they no longer need to resync and
 manually build.
 You can configure how often Maven will check for a snapshot update
 (see updatePolicy
 http://maven.apache.org/ref/3.0.3/maven-settings/settings.html#class_snapshots)

 With a continuous build system in place whenever C changes it will
 automatically schedule a build for A and B, run your unit tests and
 report success or failure.
 It should also then build Product X and Y for you (since a downstream
 dependency changed), again running your unit tests.

 You will also want a Repository Manager so that it can keep some
 control over how many SNAPSHOT versions to keep (otherwise you can
 find yourself running out of disk space)

 Hope this helps some.

 I understand the need to treat internally-developed dependencies as actual
 dependencies rather than forcing them to be modules, but I'm having some
 problems with the workflow.

 When the project is relatively new and the internally-developed dependency
 A is no where near being mature, nearly every change being made to
 Project X requires a corresponding change to A. At this point in the
 development cycle (and for many months in the foreseeable future) I actually
 /do/ need to rebuild A every time I build X.

 I can setup our CI system so that A SNAPSHOTS are built and published to
 Nexus after every commit, but what about during development, before I'm
 ready commit my changes? Am I stuck with what my IDE provides? We have
 developers using a wide range of IDEs, or no IDE at all, so I was hoping
 that Maven itself would have some way of kicking off builds of downstream
 dependency A when X is built, if in fact that's what I want to do.

Ideally you want your development to be only against releases, but as
you notice in the early days that just can't happen.

One thing I neglected to mention is that publishing SNAPSHOT to a
repository can be a pain.

The reason is that while you are happily working with your artifacts,
if a new SNAPSHOT is published and Maven decides to start downloading
it then you can find your local development hosed by bugs in the new
SNAPSHOT.
Obviously there is a trade-off here. You want to see bugs quickly so
that you can get them fixed correctly - either your code, or the
dependency. But you can also waste a lot of time if you have people
checking in things that cause breakage all the time (perhaps you then
need to investigate why that is occurring and deal with that as well).
 You should be able to manage this with the --no-snapshot-updates
option so you can when you want to pull in newer SNAPSHOTS.  Just
remember that you may have to rebuild your code again so that your
local .m2 cache has your code changes in it and not the CI version.

The next thing to ask is who is making the changes to A and X.
If it is the same person then they dont need Maven yet.
They can build via the command line, IDE, whatever.
I prefer to let the IDE (Eclipse in my case) handle the incremental
build problems.
I keep working on whatever projects I need until they are ready to
commit into version control and the IDE will ensure that everything is
building correctly so I can run my unit tests, etc all in the IDE.
I'm not using Maven at all here.

Before I commit this to version control, then I break out Maven and
build the projects in the correct order and ensure everything works.
Once committed to version control then CI will publish the SNAPSHOTS
and other developers can then decide when they want to start using the
new SNAPSHOTS.

 Right now we're simply telling folks to build A, then build X. And this
 certainly makes sense when you step back and think about it... it's just not
 terribly convenient.

If those folks are working on A and X they dont have any other
options, they want to build their code with their changes and not
suddenly get something from CI (which obviously can not have their
changes in it).
For those working with IDEs they should be able to just work in the
IDE. I'm fairly sure there is Maven integration with m2e like features
in NetBeans and IDEA.
I dont understand how you can efficiently develop without an IDE and
I'm not prepared to spend any of my time trying to help them

Re: Misunderstanding modules: Two or more projects in the reactor have the same identifier

[Barrie Treloar]

On 7 January 2014 15:29, Mark Derricutt m...@talios.com wrote:

 When the project is relatively new and the internally-developed dependency
 A is no where near being mature, nearly every change being made to
 Project X requires a corresponding change to A. At this point in the
 development cycle (and for many months in the foreseeable future) I actually
 /do/ need to rebuild A every time I build X.

 What I've often done here is create a new workspace area that contains 
 symlinks ( or git submodule checkouts ) of each of the modules I'm working 
 on, and having a simple pom.xml in the top level that sets up a reactor 
 build, then just build that.

There was also some talk about automating this step.
But its vapourware at the moment.

It would work by checking your current pom for any -SNAPSHOT
dependencies and then pulling out the source code for those and
sitting them in the parent directory.
And as you say the parent pom is just a helper that has a bunch of
modules to make building things easier - and you would never check
that pom into version control.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven Central Opinion

[Barrie Treloar]

On 6 January 2014 06:48, Curtis Rueden ctrue...@wisc.edu wrote:
 Hi Tommy,

 One of the mvn release:* commands (dont rember which ) failed if I
 did not have a SNAPSHOT version and told me the problem was that I did
 not have a SNAPSHOT version.

 I did not notice any other reply specifically troubleshooting this problem,
 so... my guess is that you have a SNAPSHOT dependency in your dependency
 hierarchy. You cannot cut a release unless it only depends on releases.
 Otherwise, the behavior of the release could change out from under you
 if/when that SNAPSHOT version is updated.

 If you share the exact error message you received, others can assist in
 more detail.

Tommy originally said - You are forced to have a SNAPSHOT version
even if you have no use for such.
So I believe that the release plugin is failing because he doesn't
have a -SNAPSHOT in his pom.
The release plugin checks that your artifact has a -SNAPSHOT version
before it starts the workflow.
If there is no -SNAPSHOT it assumes the artifact is already released
and so stops.

As others have already said, if that is not your workflow you need to
do the stuff manually instead.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need an example of calling a batch file from maven please.

[Barrie Treloar]

On 5 January 2014 11:34, rajiv rajivkumarnandv...@gmail.com wrote:
 Hi I am using maven3
 I want to execute my bat file from pom but it is not working please guide me

[del]


 i used following commands
mvn target:run
mvn verify
mvn run
mvn exe:run
mvn package

 only build success but bat file not run

Maven is not Ant.
There is too much here to explain properly and you would be much
better served to spend a few minutes reading one of the freely
available books at http://maven.apache.org/articles.html

This will give you some of the overview you need on you Maven journey.

I suspect you will even find example of how to invoke the ant plugin.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Checkstyle configLocation ignored?

[Barrie Treloar]

Sometime, a while ago, we started getting a large number of violations
which looked like the config/sun_checks.xml was being used instead of
our own checks style.
I've been ignoring it for too long now and finally had some time to investigate.

Someone else has noticed the problem:
http://stackoverflow.com/questions/8975096/maven-checkstyle-configlocation-ignored

But there is nothing in Jira.

I suspect it has to do with a change in site to move to
checkstyle:checkstyle-aggregate.

When looking at the docs
http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-aggregate-mojo.html
I also noticed that this plugin doesn't have packageNamesLocation like
checkstyle:checkstyle does. Our build used this value, but maybe its
not needed anymore as the checkstyle site report works as expected,
once I use the property checkstyle.config.location to set the value.

Has anyone else seen this problem?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: WhatWeSayWeDo != WhatWeDo

[Barrie Treloar]

On 16 December 2013 12:45, Martin Gainty mgai...@hotmail.com wrote:
 Folks-



 org.apache.maven.compiler.plugin.compiler.CompilerMojo.java

 /**
  * The source directories containing the sources to be compiled.
  */
 @Parameter( defaultValue = ${project.compileSourceRoots}, readonly = 
 true, required = true )


 For some reason I cannot locate compileSourceRoots anywhere on 
 maven-compiler-plugin page
 http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html



 do I need better glasses to read this page properly?

I had to do some googling to find where in the documentation to point
you to as I'm too rusty to be able to point you to the docs which
describes this.
I sorry to say that I struggled to find what I wanted.

A lot of this is from memory and may not be quite correct for 3.x

${project... means from the interpolate value
(http://maven.apache.org/shared/maven-filtering/) named project
which gets injected by Plexus automatically
(http://plexus.codehaus.org/plexus-components/plexus-interpolation/).
This is a MavenProject object.

The method you are talking about is here
http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/project/MavenProject.html#getCompileSourceRoots%28%29

I thought http://maven.apache.org/plugin-developers/ had some guidance
on access MavenProject but I can't find anything.

I finally found a similar example
http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook#MojoDeveloperCookbook-Themavenproject,ortheeffectivepom.
which shows you how to have a local variable get injected with this
value so you can reference it in your Mojo. But if you dont need that
variable, you can just reference its properties directly like
CompilerMojo does for the compileSourceRoots variable.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: how to run compile and packaging before test?

[Barrie Treloar]

On 13 December 2013 19:48, Malte Skoruppa skoru...@cs.uni-saarland.de wrote:
 Just scanning http://maven.apache.org and its not obvious by the
 content on the page where the books are.

 Its over in the menu on the left under Documentation  Books and Resources

 I wonder if we should add a section under Learning about Maven.

 When you might have gone looking, where would you expect to find this
 info?


 I actually only learned about the books from this mailing list. A new user
 won't usually read the entire menu. They will just scan it.
 To get started with Maven on the website, I only read the documentation
 links under User Centre. I think it would be a good idea if at least the
 Getting Started Guide had one sentence at the very end that went something
 like To find out more about Maven, check out the a href=...books/a!
 Then, at least everybody who checks out the Getting Started Guide at least
 KNOWS that there are books ;-)

Ok, I'll get around to patching that.

 Meanwhile, one doesn't necessarily have to buy a book to learn about the
 Maven lifecycle. This is also explained on the website:
 http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Yes, but it doesn't go into enough details.

The *free* books do.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven does not download the jar but it download the pom

[Barrie Treloar]

On 12 December 2013 10:11, javi.lse javier.p...@lsespace.com wrote:
 The issue is that when running mvn clean package -U (both from the command
 line and within eclipse) on the kepler SR1 only the poms were downloaded but
 not the jars. No matter what i try the jars would not get downloaded.

Did you try -X to see the debug information?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org