Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[B Smith-Mannschott]

On Mon, Jun 20, 2011 at 19:54, Paul French  wrote:
> Below is some filtered output from a maven build (showing maven meta data
> being downloaded for one artifact). All my dependencies use version ranges
> of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)
>
> In general the build fails with out of memory. I can increase the heap size
> and the build is successful, but a relatively simple build is now requiring
> 500MB heap size.
>
> First question is why is maven re-checking and downloading the same meta
> data over and over again?
>
> If I add additional version ranged dependencies to my pom then the problem
> seems to get exponentially worse. For a larger build so many requests are
> made so quickly to the nexus remote repository that I start to see "Error
> transferring file: Address already in use: connect".
>
> Any ideas how to reduce the memory usage? Do not say "do not use version
> ranges". We use semantic versioning enforced by API analysis tools for each
> of our modules (OSGi bundles) so we require version ranges.
>
> If I change all version range dependencies to an exact dependency (a serious
> amount of pom editing) then all is fine. As you can tell below we have 3
> main internal remote repos setup (kirona, kirona-snapshot and
> third.party.libraries). We do not specify version ranges on libraries that
> are not in our control e.g. log4j etc etc
>
> Downloading:
> http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
> (354 B at 21.6 KB/sec)
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> (318 B at 6.6 KB/sec)
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> (318 B at 10.0 KB/sec)
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
> (354 B at 11.2 KB/sec)
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
> (318 B at 9.7 KB/sec)
> Downloaded:
> http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
> (354 B at 10.8 KB/sec)
> Downloading:
> http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...
>
> The above problems renders eclipse useless with m2e, it causes eclipse to
> hang on start up (build automatically set to true) and eventually die!!
>
> I'm starting to come to the conclusion that between maven and m2e version
> ranges just do not work very well. I hope I am wrong!!
>
> Thanks
> Paul

In my a case I found Maven slurping metadata on every build was
related to how I had configured always in
repositories profile defined in my settings.xml (It had been a
"temporary" change which got forgotten...)

I got burned twice by version ranges. (It's at least a few years ago,
so I don't remember the specifics.) I haven't touched them since.
Also, their meaning hinges on how Maven chooses to sort versions, and
I've not yet seen a sufficiently unambiguous definition of that.
Consider that Maven will accept aNyOld3.2Crap-X1r as a version number.
 Even if you stick to the 'parse-able' versions of the form
1.2.3-mumble.

1.2.3-SNAPSHOT < 1.2.3
1.2.3-beta10 < 1.2.3-beta2
1.2.3-beta1-SNAPSHOT < 1.2.3-beta1
1.2.3-beta1 >?< 1.2.3?
1.2.3-beta1-SNAPSHOT >?< 1.2.3-SNAPSHOT

Take your best guess.

Sticking to using only SNAPSHOTs and single concrete versions is more
work if you have a large number of interdependent projects. It does
have the advan

Re: Maven and Subversion.

[B Smith-Mannschott]

On Tue, Apr 19, 2011 at 20:38,   wrote:
> I am wondering if anyone has a good solution to the following issue.
>
> I have a  multi module maven configuration ( a pom that runs multiple poms 
> underneath it.).  I made it a multi module project because the sub projects 
> are very similar and it is convenient to run them all from one pom.  However, 
>  I need each of these sub projects to be versioned independently.  In 
> subversion, you need to make trunk, tags, and branches folders for each 
> project to do this.   This breaks the multi module directory structure for 
> Maven as it requires the pom to be in the top level folder for each of the 
> sub projects.
>
> Does anyone have a solution as to the best way to make this work, or am I 
> stuck with not using the multi module project  in Maven?
>
> Thanks,
>
> Todd

In our repository we have the policy that only modules that are always
released together can live in the same trunk. As a result we don't
have many multi-module builds.  This isn't all rainbows and unicorns,
as this means more individual trunks to tag, more versions to keep
track of, more things to build and deploy etc.

For such cases, we've used svn:externals to pull together a few large
(50 modules) multi-module builds. So far, this has worked out OK. You
can't sensibly maven release:perform from the root of such a project.
When it's time to release you still have to do each sub-module
separately. During development, however, it's a convenient way to
check everything out and build everything together.


Super simplified example:

/repo/project-a/trunk (development, 1.1-SNAPSHOT)
/repo/project-a/branches/1.0.x (a 1.0.x-SNAPSHOT release branch)
/repo/project-a/tags/1.0.0
/repo/project-b/trunk (development, 1.2-SNAPSHOT)
/repo/project-b/branches/1.1.x (a 1.1.x-SNAPSHOT release branch)
/repo/project-b/tags/1.1.0

/repo/combined-release/trunk
contains a pom.xml naming the submodules and defines svn:externals for
/repo/project-a/trunk
/repo/project-b/trunk

/repo/combined-release/branches/1.0.x
contains a pom.xml naming the submodules and defines svn:externals for
/repo/project-a/branches/1.0.x
/repo/project-b/branches/1.1.x

/repo/combined-release/tags/1.0.0
contains a pom.xml naming the submodules and defines svn:externals for
/repo/project-a/tags/1.0.0
/repo/project-b/tags/1.1.0

Making something like the above release tag means editing the
svn:externals to point at the correct project tags. There's no way (I
know of) of getting maven to do this, as it's pretty SVN specific.

// ben

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

how can I filter svn 'last changed date' into a collection of files?

[B Smith-Mannschott]

Here's my situation:

- I'm publishing a user manual as a collection of HTML files in a JAR file.

- My sources are in Subversion

- I'd like to include in each HTML file the date when changes to *that
HTML file* were most recently comitted to Subversion.

This sounds like resource filtering, except that I'm not substituting
a fixed text for every occurance of ${LAST_CHANGED_DATE}, instead the
text substituted would be particular to each file and provided by
Subversion.

Does anyone know of a Maven plugin to filter Subversion "last changed
date" into resources during build?  I'm open to other suggestions on
how to accomplish this as well.

// Ben

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

Re: Mysterious error on site:site

[B Smith-Mannschott]

On Sun, Aug 16, 2009 at 16:20, B Smith-Mannschott wrote:
> On Sat, Aug 15, 2009 at 00:18, Sam
> Barnett-Cormack wrote:
>> Further note:
>>
>> this happened when I added the following (host address edited):
>>
>> http://host.domain.co.uk/~sdb/maven/${project.artifactId}
>>
>> to the *parent* POM. I comment it out, it's all fine. I call this weird, but 
>> would love an explanation.
>
> I've been seeing NPEs when doing site generation since updating to mvn
> 2.2.0. I define  using a property in my parent pom.
>
> I've looked at the release notes to 2.2.1, but it's not clear to me if
> that may fix this problem. (There's talk of at least 3 NPE bugs fixed,
> but none of them are obviously this one.) I'll try it out on monday
> when I'm back at the office and report back.

Upgrading to 2.2.1 was no help with the NPE issue I was observing
(which may or may not be the same as the one described by the OP.)

// Ben

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

Re: Mysterious error on site:site

[B Smith-Mannschott]

On Sat, Aug 15, 2009 at 00:18, Sam
Barnett-Cormack wrote:
> Further note:
>
> this happened when I added the following (host address edited):
>
> http://host.domain.co.uk/~sdb/maven/${project.artifactId}
>
> to the *parent* POM. I comment it out, it's all fine. I call this weird, but 
> would love an explanation.

I've been seeing NPEs when doing site generation since updating to mvn
2.2.0. I define  using a property in my parent pom.

I've looked at the release notes to 2.2.1, but it's not clear to me if
that may fix this problem. (There's talk of at least 3 NPE bugs fixed,
but none of them are obviously this one.) I'll try it out on monday
when I'm back at the office and report back.

// ben

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

Re: Why is version 2.0 NOT same as 2.0.0?

[B Smith-Mannschott]

On Tue, Jun 16, 2009 at 09:15, Paul Benedict wrote:
> It may seem strange that 2.0.0 is not the same as 2.0, but it's not
> totally unstrange. It is a matter of precision.
>
> Did you know BigDecimal("2.00") does not equal BigDecimal("2.0")?
>
> The second situation can be rectified by a setting. Perhaps the first
> (in Maven) should too.
>
> Paul

I don't think this line of arguments applies here. **versions are not
floating point numbers!**

A version is generally treated as a tuple of integers, which are then
lexicographically compared.  That is:

"2.0" -> (2, 0)
"2.0.0" -> (2, 0, 0)
"2.13.34" -> (2, 13, 34)

But the real world is messy, which raises questions:

(1) Does the tuple of integers have some maximal length ("precision")
or is it effectively unbounded.
-> in Maven's case it's bounded at length 3. [[I wish it were unbounded]]

(2) How do we treat the "missing" places when comparing two tuples of
differing length?
-> Maven treats these places as 0 (zero) when comparing artifact versions.

(2, 0) == (2, 0, 0)

Otherwise, a normal lexicographical sort would yield: (2, 0) < (2, 0,
0), just as "park" < "parka".

(3) Do we allow non-numeric parts in the version?
-> Maven does allow a qualifier which is effectively compared as a
string. (Followed by a dash and build number, except this is broken
according to the docs and is parsed as part of the qualifier.)

Effectively, it is as if maven sorts "2.0-qualifier" as if it were the
tuple (2, 0, 0, "qualifier").
2.0-qualifier -> ( (2, 0), "qualifier" ) -> (2, 0, 0, "qualifier")

(4) How do we handle versions that don't have the expected syntax?
-> Maven punts and considers such versions to be either always greater
or always lesser than parseable versions. (I don't recall which). [[I
wish Maven had chosen to be "opinionated" about the format of version
numbers and mandated that they all be parseable. It is, after all,
opinionated about a great many other things and sanity in versioning
would seem be to central to the whole resolution magic it tries to
do.]]

// Ben

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

Re: Why is version 2.0 NOT same as 2.0.0?

[B Smith-Mannschott]

> 2009/6/14 B Smith-Mannschott :
>> On Sat, Jun 13, 2009 at 22:56, Jim Sellers wrote:
>>> I assume that maven treats them as Strings internally, not doubles.
>>>
>>> Just like version 3.0-RC1 and 1.0.3-beta3 are valid versions.
>>>
>>
>> Doubles!? How would you make a double out of 2.0.0? Nonsensical.
>>
>> http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html
>>
>> Maven version numbers generally have this form:
>>
>> ..-
>>
>> The version parts are treated as integers. Missing numeric parts are
>> considered zero. The qualifier is compared as a string. Any version
>> not following this syntax is treated purely as a string.
>>
>> I don't recall if unparseable versions always sort before or always
>> after parseable version numbers. It's been a while since I read the
>> code that actually takes care of this. It made me throw up a little
>> inside.
>>
>> // ben

On Sun, Jun 14, 2009 at 19:25, Stephen
Connolly wrote:
> however 2.0 and 2.0.0 are both parseable versions.
>

True, and they should be equivalent. Indeed the OP's second post
demonstrates this. So, whatever the explanation for the OP's issue,
it's not that parsing and comparision of versions is somehow
mysteriously broken.

// ben

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

Re: Why is version 2.0 NOT same as 2.0.0?

[B Smith-Mannschott]

On Sat, Jun 13, 2009 at 22:56, Jim Sellers wrote:
> I assume that maven treats them as Strings internally, not doubles.
>
> Just like version 3.0-RC1 and 1.0.3-beta3 are valid versions.
>

Doubles!? How would you make a double out of 2.0.0? Nonsensical.

http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-pom-syntax.html

Maven version numbers generally have this form:

..-

The version parts are treated as integers. Missing numeric parts are
considered zero. The qualifier is compared as a string. Any version
not following this syntax is treated purely as a string.

I don't recall if unparseable versions always sort before or always
after parseable version numbers. It's been a while since I read the
code that actually takes care of this. It made me throw up a little
inside.

// ben

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

how is hudson's "maven generated site" link intended to work for multi-module maven builds?

[B Smith-Mannschott]

I'm sending this missive to user's lists of both hudson and maven
because it concerns using these two tools together, and I'll need help
from both parties to make this work.

Rather than separately site-deploying the sites of the 30 or so maven
projects hudson is building for me at work, I've decided to take
advantage of hudson's handy "maven generated site" link. (Now that it
works again!)

This works quite well for single-module maven builds.

Multi-module builds, not so much.

I have a few multi-module maven projects at work, and here are the problems:

(1) Hudson's "maven generated site" link links to one of the
sub-modules instead of linking to the site of the multi-module pom
project at the root of the defined working copy.

(2) Even if it *did* link to the correct project, instead of some
random sub-project, it wouldn't work since links to sub-modules are
broken.

(3) Links to sub-modules are broken. They expect to find in
target/site/submodule, what is in fact in submodule/target/site.

(4) Links to sub-modules are not even generated unless it happens that
the multi-module pom project is also the  of each of the
submodules. Why this is, is anyone's guess.

(5) They will work, if the site is deployed, but then  must be
defined correctly.

(6) One thing that works, but is ugly is:
http://example.com/${groupId}/${artifactId} in the
parent/multi-module pom. The children end up all installing to
http://example.com/${groupId}/${project.artifactId}/${project.artifactId},
which is just kind of gross, instead of
ttp://example.com/${groupId}/${parent.artifactId}/${project.artifactId},
but I guess that's an effect of the ${} expansion being after, not
before inheritance is performed.

But, if I deploy the site, I need to separately maintain a page of
links to those sites, since Hudson's "maven generated site" link does
not go there, it goes to target/site. I also have a whole separate set
of URLs to manage, to advertise to my users and to clean up when I
remove corresponding build jobs. Messy.

I'm trying to simplify my life, not complicated it.


Is there some way I can get my multi-module projects to produce a site
which is accessible through hudson and which makes submodules
available? Alternately, perhaps it would be possible to somehow
intelligently combine the project reports from the various submodules
and merge them all into the site of the multi-module build.


I've reached the point now where I'm tempted to just break out beat
the problem into submission with a generous helping of shell
scripting, but that doesn't seem very 'mavenesque'.

Has anyone out there already solved this, or a similar problem?

// Ben

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

Re: Slow maven compile after upgrading JDK from 1.5 to 1.6

[B Smith-Mannschott]

On Mon, May 25, 2009 at 11:38, j_ri  wrote:

> another question I have is the follwing:
> why does maven put all transitive dependencies in the compile classpath? it
> is best practise to have all jars I really depend on for my compilation as
> direct dependency in my pom. why don't force this and just put the direct
> dependencies in the compile classpath and pass the transitive ones "only" to
> the other tasks (packaging, etc.)?

A: provides class Foo {}

B: provides function getTheFoo() -> Foo
B: has a compile time dependency on A

C: has a compile-time dependency on B
C: calls getTheFoo(), which returns a... oops.

B can use types form A in its public interface. Do we really want to
force all C's to know which of B's dependencies appear in its public
interface? Or do all B's document which dependencies they "re-export",
i.e. which should be considered transitive, and which not?

Actually, that last idea, might not be so bad...

// ben

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

Re: Does reactor spawn a subprocess for each submodule?

[B Smith-Mannschott]

On Fri, May 22, 2009 at 6:43 PM, Tracy Hartford  wrote:
> I am working on a large multi-module project, and I need to know how the
> reactor works when I invoke a maven goal on the parent POM. I know that
> Maven adds all the submodule POMs into the Reactor, which analyzes the
> dependencies between them, and determines the build order. I understand
> that the Reactor then "effectively executes" the goal for each
> submodule. What I need to know is, when the Reactor executes the goal
> for a given submodule, does it spawn a child process to do so, or does
> it execute in the current process? If it execute in the current process,
> is there a way to force it to spawn a new process first?

On Sun, May 24, 2009 at 14:50, Brian Fox  wrote:
> It runs inside the same process. You can use the invoker to fork a maven
> process, but this is not usually done as you describe. Why do you want to
> fork a new process for each module?

One might do so hoping to allow builds to run in parallel on a
multi-core machine. Not that there'd be much point since maven's local
.m2/repository is not safe for concurrent access:

http://jira.codehaus.org/browse/MNG-3004

// ben

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

Re: How to generate javadoc jar only during deploy?

[B Smith-Mannschott]

Move the configuration into a profile. Only runs when the profile is
activated explicitly


... mumble ...


generate-javadocs
...mumble...


   org.apache.maven.plugins
   maven-javadoc-plugin
   2.5
   
   
   attach-javadocs
   
   jar
   
   
   
   

   ... mumble ...




$ mvn -Pgenerate-javadocs deploy   < instally/deploy with javadocs
$ mvn deploy <-- install/deploy without javadocs


// ben

On Mon, Apr 13, 2009 at 18:16, David Hoffer  wrote:
> Attaching to the install phase doesn't accomplish what I was looking for.
> This still generates javadocs for install goal it just doesn't publish it to
> the local repo.
>
> I suppose its better than no change but the problem is that this still
> causes javadocs to be generated and then the IDE sees these and has to
> reindex, etc, its a slow process and we really don't need new javadocs for
> every developer build.
>
> -Dave
>
> On Mon, Apr 13, 2009 at 9:52 AM, David Hoffer  wrote:
>
>> Okay, i will try install phase.
>>
>> thanks,
>> -Dave
>>
>>
>> On Mon, Apr 13, 2009 at 9:42 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> nope as attaching to the deploy phase means that it gets to run after the
>>> lifecycle plugins (ie after deploy:deploy) therefore you need to attach it
>>> to an earlier phase (and the latest earlier phase available is install)
>>>
>>> Sent from my [rhymes with myPod] ;-)
>>>
>>>
>>> On 13 Apr 2009, at 15:09, David Hoffer  wrote:
>>>
>>>  Thanks much, I think you intended to say deploy.

 -Dave

 On Sat, Apr 11, 2009 at 12:08 PM, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

  2009/4/10 David Hoffer 
>
>  My project currently creates javadocs during the install goal, see pom
>> below.  How can I configure this to run only if deploy goal is run
>>
> instead?
>
>>
>> Alternatively, is there a way this can be externalized so that
>> individual
>> developers can turn this feature off when they do an install?
>>
>> 
>>              org.apache.maven.plugins
>>              maven-javadoc-plugin
>>              2.5
>>              
>>                  
>>                      attach-javadocs
>>
>
> install
>
>
>>                      
>>                          jar
>>                      
>>                  
>>              
>> 
>>
>>
>
>>> -
>>> 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

Re: Central index redirect

[B Smith-Mannschott]

On Fri, Apr 3, 2009 at 07:31, Wayne Fay  wrote:
>> and improve access time for other artifacts. (224m downloads and 24TB
>> last month alone for the index) The index is not accessible from
>
> I find it amazing that there were 224 million downloads of a single
> file in Central last month! That sounds more like the total usage of
> Central, astounding. (Curious is you have those numbers available
> too...)
>
> Are there misconfigured tools out there in the world that are causing
> this file to be downloaded every single time a build executes, or
> something along those lines??
>

I recently noticed that the default install of m2eclipse looks like it
downloads the index from central every time eclipse is started. I
hadn't expected this since I've got settings.xml configured to mirror
everything through the local nexus which has a copy of the index.

It seems it will be necessary to have each developer configure their
m2eclipse manually to get the indexes from the local nexus, though
behavior will revert to the default every time they set up a new
workspace, so really, there's no way to truly stay on top of this.

Surely, there must be a better way. What am I overlooking?

// ben

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

Re: Sharing Maven-based project

[B Smith-Mannschott]

On Sun, Mar 29, 2009 at 16:08, HHB  wrote:
>
> Hey,
> I use Maven as the build tool for our project.
> Now my team mates want to checkout the project from the SVN and I want to
> add the project to out continuous integration server (Hudson).
> I'm not sure but should I create a central repository in our unit? or let
> each mate (and CI server) download the dependency himself?
> What repository manager do you suggest?
> Thanks.

I use a combination of Nexus[1] for my maven artifacts and Hudson[2]
for continuous build. Both were very easy to set up and maintain.

[1] http://nexus.sonatype.org/
[2] https://hudson.dev.java.net/

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

Re: How to perform a deploy only

[B Smith-Mannschott]

On Thu, Mar 26, 2009 at 03:17, Jim McCaskey  wrote:
> Hello all,
>
> I have several components all built from a top level pom.  This works great 
> for accelerating users to be able to build a lot of stuff quickly but is 
> giving me some fits when trying to deploy.  Up to this point I have been 
> using deploy:deploy-file to get built components into our local repository 
> after a full build is successful, but this is labor intensive.

My Guess: It sounds like you're describing a multi-module build where
the "top-level" pom naming the modules to be built is also parent to
the sub-modules. You want to deploy just the top-level pom, so others
can build against it. Correct? You don't want to deploy all the
sub-modules each time you do this because they may not be in a stable
state.

(1) Have you considered "mvn --non-recursive deploy"?
(2) You do realize that the pom that defines the modules does not have
to be the same as the common parent pom, yes?



// ben

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

Re: Possible problem when multiple developers depend on SNAPSHOT versions

[B Smith-Mannschott]

With all due respect to others' responses, the scenario described
below is not due to misuse or lack of version control. Indeed, the
scenario below clearly describes version control *working as
designed*.

Bob finds himself unwittingly building snapshots of 2.2, while his
project continues to depend on snapshots of 2.1, so he doesn't see his
own changes. The problem, however, is neither source control nor
maven: it's lack of communication.

Something like cutting a release needs to be coordinated among the
developers working on a component. Alice and Bob need to talk to each
other about library Foo, particularly with respect to cutting a
release. There's no way around this.

// ben

On Wed, Mar 25, 2009 at 20:10, Trevor Harmon  wrote:
> Consider this scenario:
>
> Alice and Bob are working independently on two different applications, AppA
> and AppB. Both applications depend on an in-house shared library, Foo, that
> Alice and Bob are working on together. They have both checked out Foo's
> trunk and are regularly committing changes to it.
>
> Because Foo is undergoing heavy development, AppA and AppB depend on Foo
> 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs
> some of the features scheduled for Foo 2.2, so she decides to perform a
> release of Foo 2.1 and does the usual release procedure:
>
> 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the
> trunk
> 2) Deploys Foo 2.1 to the company's internal repository
> 3) Tags the Foo trunk as the 2.1 release branch
> 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the
> trunk
> 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT
>
> But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB.
> If he updates his working copy of Foo's source code, any changes he makes to
> Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now
> 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on
> 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo
> 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste
> a lot of time debugging, at least until he happens to notice that Foo's
> version has changed.
>
> What can be done to prevent Bob's problem?
>
> Trevor
>
>
> -
> 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

building clojure with maven; the bootstrapping problem

[B Smith-Mannschott]

I've been attempting to expand my understanding of maven by teaching
it to build clojure [1,2].

[1]: http://clojure.org
[2]: http://clojure.googlecode.com/svn/trunk
[3]: git://github.com/kevinoneill/clojure.git

Clojure already has a maven build, but all it does is package up the
build products left behind by a previously executed ant build. I'd
like a solution that's "pure maven". That would fit best into my
existing work-flow and build server. Consider this a first baby-step
toward "clojure-compiler-maven-plugin", if you like.

The "kernel" of clojure (runtime library, which includes the compiler)
is written in Java. The rest is written in Clojure. It is possible to
just compile the just the java and then package the clojure sources
together with the class files. This will work, but it's slow to start
up since the core clojure libraries must be compiled from source at
loading. It's more efficient to use the clojure to compile the clojure
sources ahead of time to class files. (This is essentially what the
ant build does.)

#!/bin/bash
mvn clean  # pom file included at end of message
# this compiles the java part of clojure, and copies the clojure
# sources to target/classes unchanged.
mvn compile
# this compiles the clojure sources, which have been copied to
# target/classes in place.
java -Dclojure.compile.path=$classes \
-cp target/classes clojure.lang.Compile \
clojure.core \
clojure.main \
clojure.set \
clojure.xml \
clojure.zip \
clojure.inspector
# this packages it all up: clojure sources, class files from java,
# class files from clojure.
mvn package

This is obviously a hack, and not "pure maven" by any stretch. How
would an experienced maven user go about this?

(1) Is there a way to embed imperative logic in the pom, perhaps with
a fragment of ant, and get it to run at the correct stage during the
build life cycle?

(2) This problem would be "solved" if we had a
clojure-compiler-maven-plugin to call upon, but of course if we wanted
it to perform well, we'd want to make sure that the copy of clojure it
used had itself been built with the clojure-compiler-maven-plugin. ;-)

How would you, as a maven user, go about this?

// ben

--


http://maven.apache.org/POM/4.0.0";
 xmlns:xsi="http//www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0
  
  org.clojure.bpsm
  clojure-lang
  clojure-lang
  1.0-SNAPSHOT
  http://clojure.org/

  Clojure runtime library (and compiler).

  

  Eclipse Public License 1.0
  http://opensource.org/licenses/eclipse-1.0.php
  repo

  

  

src/jvm

  

src/clj
  


  
org.apache.maven.plugins
maven-compiler-plugin

  
  1.5
  1.5

  
  
org.apache.maven.plugins
maven-jar-plugin
2.2

  

  true
  clojure.main

  

  
  
org.apache.maven.plugins
maven-source-plugin

  
attach-sources
package

  jar

  

  

  



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

Re: Replace Dynamic Revisions during

[B Smith-Mannschott]

On Thu, Mar 5, 2009 at 08:15, Martin Eigenbrodt
 wrote:
> Thanks for your response Ben,
> I've considered this workaround, but I need a way to always pick the latest
> build of a dependend project. I know there are
> "SNAPSHOT" Builds but those break the paradigm "a revision never changes".
> Even if I used snapshot build, for each release I would have to pull a
> release for each dependency to get a "Snapshot Free" release. Or is this
> done automatically by the release plugin?
>
> Martin

The release plugin *is* clever enough to ask you if you want to
replace SNAPSHOT versions in your dependencies with real release
versions. Once it's gotten the necessary information from you, it
makes the edits on your behalf. A good feature, that.

The problem with "always picking the latest build" is that you won't
know anymore which that was when you check out a two-month old tag
form source control and try to repeat the build. I too have projects
where I want my dependencies to always go to the latest build. I just
go through the drudgery of updating users when such a library has a
new release.

Speaking of releases, I read something in Sonatype's Maven book about
using RELEASE as the version for a dependency. Supposedly this will
always take the newest released version (SNAPSHOTs are not
considered). It hasn't worked for me (mvn 2.0.9), I assume this
feature will come along in the next version.

// ben

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

Re: Replace Dynamic Revisions during

[B Smith-Mannschott]

On Thu, Mar 5, 2009 at 07:50, Martin Eigenbrodt
 wrote:
> I've tried the release plugin (when i wrote "performed a release" i meant
> mvn release:prepare followed by mvn release:perform). That tag created in my
> svn does contain the dynamic revision, as I wrote above. So the build is not
> reproducible unless you backup all involved maven repositories: If a new
> Version of any dependency is published even compiling the taged version can
> fail.
>

For this reason (among others) I never use maven's version ranges.

(Also, the syntax of version ranges makes me throw up a little. In
fact, I've been using maven for years now and I *still* haven't
decided if I love it or hate it.)

//ben

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