Re: [VOTE] Change project logo and adopt owl as mascot

[Mark Struberg]

+1

really like the new logo (or better any of those owls).

LieGrue,
strub





> On Tuesday, 25 November 2014, 12:02, Arnaud Héritier  
> wrote:
> > +1
> 
> thx
> 
> 
> On Tue, Nov 25, 2014 at 11:57 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>>  +1
>> 
>>  On 25 November 2014 at 10:57, Stephen Connolly <
>>  stephen.alan.conno...@gmail.com> wrote:
>> 
>>  > For anyone who has been living under a rock, here is the background
>>  >
>>  > Background
>>  > =
>>  >
>>  > I think everyone can agree that the site needs a reorganisation and a
>>  > rewrite. Users cannot find what they need, and the end result is that
>>  > people keep on abusing maven rather than having maven help them.
>>  >
>>  > Try as I might, I have been unable to motivate myself to do the
>>  > reorganisation with the current dated look and feel of the site... I 
> am
>>  not
>>  > saying that picking a new logo and selecting a mascot will result in
>>  making
>>  > progress, but it can't hurt and I believe it will help
>>  >
>>  > Proposed changes
>>  > ===
>>  >
>>  > 1. Change the logo font to Alte Haas Grotesk Bold with italics applied 
> by
>>  > Inkscape
>>  > 2. Change the highlighted letter from 'a' to 'v' and 
> replace the v with
>>  > two Apache Feathers
>>  > 3. Adopt the (currently unnamed) owl as our mascot
>>  >
>>  > Here is a link to the font:
>>  >
>>  > http://www.dafont.com/alte-haas-grotesk.font
>>  >
>>  > Here is a large version of the owl and the logo:
>>  >
>>  >
>>  >
>> 
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-large.png
>>  >
>>  > A regular version of the own and the logo, e.g. a size suitable for 
> use
>>  in
>>  > the top of the standard maven sites:
>>  >
>>  >
>>  http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final.png
>>  >
>>  > (Note that in all likelihood, the mascot would probably end up on the
>>  > other side of the title bar from the logo... and that is IF the mascot
>>  ends
>>  > up on the title bar)
>>  >
>>  > Here is both of those rendered in a site (as it can be helpful to see 
> the
>>  > graphics adjacent to text)
>>  >
>>  >
>>  >
>> 
> http://people.apache.org/~stephenc/maven-logo-contest/maven-owl-final-context.png
>>  >
>>  >
>>  > Logo Rational
>>  > ===
>>  >
>>  > If we do some searches for the Maven logo:
>>  >
>>  >
>>  >
>> 
> https://www.google.com/search?site=imghp&tbm=isch&q=maven+logo&oq=maven+logo
>>  >
>>  >
>>  >
>> 
> http://www.bing.com/images/search?q=maven+logo&go=Submit&qs=n&form=QBLH&scope=images&pq=maven+logo
>>  >
>>  > Our current logo, with a single highlighted letter stands out quite 
> well
>>  > from the other "maven" logos, so keeping a highlighted 
> letter and an
>>  italic
>>  > rendered font maintains continuity with our current logo.
>>  >
>>  > By changing the highlighted letter to the `v` and by using two Apache
>>  > feathers to create the `v`, we connect our logo back to Apache... we 
> are
>>  > Apache Maven after all.
>>  >
>>  > The `v` is also the common short term for version (e.g.v3 is short for
>>  > version 3). Apache Maven puts a lot of emphasis on versions of
>>  dependencies
>>  > and plugins... you could say that versions are very important to 
> Maven.
>>  >
>>  > The colours of the feather were changed to solid colours to match the 
> owl
>>  > mascot's scarf, beak and eyebrows
>>  >
>>  > Voting rules
>>  > =
>>  >
>>  > Anyone who is subscribed to the dev or users list is eligible to vote.
>>  >
>>  > If you vote multiple times, only your final vote will be counted.
>>  >
>>  > The vote will be open until 1:00pm GMT on Wed 3rd Dec 2014
>>  >
>>  > The vote is for all three changes as one single change. Partial votes
>>  > (e.g. for the logo but not the mascot, or vice-versa) will not be
>>  counted.
>>  >
>>  > I, as the caller of the vote, reserve the right to cancel the vote if
>>  this
>>  > vote is putting the harmony of the community at risk.
>>  >
>>  > If a majority of the PMC believe that this vote is putting the harmony 
> of
>>  > the community at risk, then the PMC may cancel this vote (though if 
> even
>>  a
>>  > small minority of the PMC were of that belief, I will more than likely
>>  have
>>  > cancelled the vote before the PMC would need to decide... I'm just
>>  stating
>>  > this FTR)
>>  >
>>  > The decision will be a simple majority, there will be no special veto
>>  > powers.
>>  >
>>  > +1: [ ] Change the logo to the proposed logo and adopt the owl as 
> project
>>  > mascot
>>  > 0: [ ] No opinion
>>  > -1: [ ] No change
>>  >
>>  > Please only respond with +1, 0 or -1. If you want to discuss the 
> proposed
>>  > changes please use a different thread. This thread is for voting only.
>>  >
>>  > -Stephen
>>  >
>> 
> 
> 
> 
> -- 
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Open Source Best Practices with Maven - distributionManagement

[Mark Struberg]

You could also add those properties into a profile in your settings.xml. That 
way you don't even have the url in the projects pom anymore.
Downside: this needs to be set up on each of your colleagues computers.

LieGrue,
strub





On Wednesday, 19 March 2014, 23:16, Eric Kolotyluk  
wrote:
 
OK, this was great advice. :-)
>
>This works nicely because I do not have to have separate profiles in my 
>pom.xml for my local Nexus or Sonatype's remote one. This keeps the 
>pom.xml smaller.
>
>This would be a nice narrative to add to 
>https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
>Getting arbitrarily closer to pushing my first artifact ever to Maven 
>Central...
>
>Cheers, Eric
>
>On 3/19/2014 2:15 PM, Mirko Friedenhagen wrote:
>> Hello Eric,
>>
>> as outlined in 
>> https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
>> in your settings.xml you might define properties
>> altReleaseDeploymentRepository and altSnapshotDeploymentRepository in
>> a profile internal-repository which is activated by default while you
>> do not define any repository at all in your pom.
>> Now while developing you just invoke mvn deploy and everything should
>> go to your local Nexus.
>> When invoking mvn -P!internal-repository everything should go to central.
>> Regards Mirko
>> --
>> http://illegalstateexception.blogspot.com/
>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
>> https://bitbucket.org/mfriedenhagen/
>>
>>
>> On Wed, Mar 19, 2014 at 9:39 PM, Stevo Slavić  wrote:
>>> Hello Eric,
>>>
>>> I'd consider using Sonatype OSS with Sonatype OSS parent pom and everything
>>> that goes along (see more details at
>>> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide)
>>> For OSS development maybe use private (and not local) Nexus as proxy only,
>>> with mirrors defined in local settings.xml, but publish both snapshots and
>>> releases to Sonatype OSS repositories which get synced to Maven Central.
>>> Why run Nexus on local machine? To control dependencies and their metada
>>> for yourself only? Still looks as overkill to me, if you're the sole user
>>> and plan on developing OSS. You already have local repository, and you
>>> should have same experience as your OSS users (so no custom local metadata
>>> of dependencies, depend only on stuff available on Maven Central, with
>>> metadata as it is published on Maven Central).
>>>
>>> Kind regards,
>>> Stevo Slavic
>>>
>>>
>>> On Wed, Mar 19, 2014 at 9:23 PM, Eric Kolotyluk 
>>> wrote:
>>>
 Does anyone know of any good documentation on 'Open Source Best Practices
 with Maven'

 For example, in my POM, I want to set up

    
 http://localhost:8081/nexus/content/groups/public
 
      
        false
        nexus-kolotyluk
        Local Release Repository
 http://localhost:8081/nexus/content/repositories/releases
        default
      
      
        nexus-kolotyluk
        Local Snapshot Repository
 http://localhost:8081/nexus/content/repositories/snapshots
        default
      
    

 But that is my local repository on my development computer.

 If I want to push my project to Maven Central some day, I don't think I
 want this in my POM.

 Should I put this in a parent POM, or inside a  of my
 settings.xml file?

 If I put it in a parent POM, then I need to push that to Maven Central
 too, so that does not sound like a good idea.

 Cheer, Eric

 -
 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
>>
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>

Re: Are skinny WARs still recommended?

[Mark Struberg]

It depends. This is true for resources accessed via EL #{resource} (which I do 
not recommend btw because it's a HUGE performance hog - better use restful 
resources [1]). For facelets this only got fixed in JSF-2.2. In JSF-2.0 and 2.1 
you still need the ResourceResolver to load facelets from a jar [2].

LieGrue,
strub

[1] 
http://www.jakobk.com/2011/11/bachelor-thesis-about-relative-resource-handler/
[2] 
http://stackoverflow.com/questions/6199458/how-to-create-a-modular-jsf-2-0-application/6201044#6201044





On Friday, 28 February 2014, 8:39, Martin Hoeller  wrote:
 
On 27 Feb 2014, Mark Struberg wrote:
>
>> JSF by default loads the resources from the local WAR classpath only. But 
>> you can easily write your own ResourceResolver which picks the stuff from 
>> the ClassPath as well.
>> 
>> An example can be found here:
>> http://ocpsoft.org/opensource/create-common-facelets-jar/
>> See CustomResourceResolver.
>
>Very big on the linked site is stated "In JSF2, this process is no longer
>required.". An we are talking about JSF2 here.
>
>Beside this, (as far as I understood it) the ResourceResolver is just
>responsible for resolving resources like images, CSS and the like at
>application runtime. We are talking about registering component,
>converters, etc. at application startup time here and I don't think the
>ResourceResolver could be any help in this case.
>
>thx anyway,
>
>- martin
>
>

Re: Are skinny WARs still recommended?

[Mark Struberg]

JSF by default loads the resources from the local WAR classpath only. But you 
can easily write your own ResourceResolver which picks the stuff from the 
ClassPath as well.

An example can be found here:
http://ocpsoft.org/opensource/create-common-facelets-jar/
See CustomResourceResolver.


LieGrue,
strub


On Thursday, 27 February 2014, 18:40, Simon Lessard  
wrote:

Hi,
>
>From a pure JSF point of view, you could also add a
>WEB-INF/faces-config.xml file in your project that redefine all OmniFaces
>artifact that are annotated. It's a super poor man solution/ugly hack as
>you might have to alter the file with every OmniFaces releases, but would
>allow you to have the OmniFaces JAR in the EAR while still have everything
>it provides available. I agree with Antonio's suggestion to ask for a
>library split within OmniFaces as a more future-proof solution.
>
>
>Regards,
>
>
>
>On Thu, Feb 27, 2014 at 5:31 PM, Antonio Petrelli <
>antonio.petre...@gmail.com> wrote:
>
>> 2014-02-27 17:26 GMT+01:00 Martin Hoeller :
>>
>> > On 27 Feb 2014, Antonio Petrelli wrote:
>> >
>> > > 2014-02-27 17:14 GMT+01:00 Martin Hoeller :
>> > >
>> > > > On 27 Feb 2014, Antonio Petrelli wrote:
>> > > >
>> > > > > 2014-02-27 17:05 GMT+01:00 Martin Hoeller :
>> > > > >
>> > > > > > I have another concrete example with a single WAR where OmniFaces
>> > is a
>> > > > > > dependency by the WAR and by some EJB JAR, both contained in the
>> > EAR.
>> > > > The
>> > > > > > OmniFaces JAR goes in the EARs lib folder and thus OmniFaces ist
>> > not
>> > > > > > fully usable without workarounds. See also my question on
>> > > > StackOverflow:
>> > > > > >
>> > > > > >
>> > > >
>> >
>> http://stackoverflow.com/questions/22046464/how-to-correctly-use-omnifaces-in-an-ear
>> > > > > >
>> > > > > >
>> > > > > Hi,
>> > > > > the real question is: why do you want to use a JSF-specific library
>> > > > inside
>> > > > > an EJB?
>> > > >
>> > > > OmniFaces is a JSF library but not UI component focused like
>> RichFaces.
>> > > > It hast some really nice classes like BeanManager that could be
>> useful
>> > > > outside a JSF application.
>> > > >
>> > >
>> > > If it's really BeanManager or few classes that you need, I suggest to
>> use
>> > > the Shade plugin, to create an artifact with one (or few) classes,
>> > possibly
>> > > moved to another package:
>> > >
>> >
>> http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
>> >
>> > I was already thinking of this :)
>> >
>> > However, I felt like there would be something wrong with this approach,
>> as
>> > I usually just need to declare a dependency when I want to use a library.
>> > Not repackage it and include the classes twice in the EAR.
>> >
>>
>> In fact what I proposed is a workaround. Probably you could collaborate
>> with OmniFaces to split the library into a "common" jar and a JSF-specific
>> jar, so that the common can be safely put in the EAR.
>>
>> Antonio
>>
>
>
>
>-- 
>*Simon Lessard*, ADF Architect
>*CMA* *SYSTeMS*
>*( +33(0) 6 79 37 39 85 (France)*
>
>
>
>

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

Re: Seeking feedback on “Recursive Maven considered harmful”

[Mark Struberg]

By default it should be fine to use the 'mvn verify' build lifecycle step [1]. 
In that case the 'reactor' does not reference the project dependencies via the 
local maven repo but instead via path JVM references to the other modules in 
the build directly.

LieGrue,
strub



[1] 
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html



- Original Message -
> From: Laird Nelson 
> To: Maven Users List 
> Cc: 
> Sent: Monday, December 17, 2012 4:34 PM
> Subject: Re: Seeking feedback on “Recursive Maven considered harmful”
> 
> On Mon, Dec 17, 2012 at 3:36 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>>  Another issue is that people abuse the "install" hack far more 
> often than
>>  they should...
>> 
> 
> Hi; this is the first I've read anywhere about the "install 
> hack".  Where
> can I find out more about it?
> 
> 
>>  In fact it seems most people's default mode with Maven is to go 
> "mvn clean
>>  install".
>> 
> 
> Guilty as charged in a multi-module build.  Are you saying there's another
> way that modules in a multi-module build can share artifacts?  Could you
> point me to where this is documented?
> 
> 
>>  of course the real
>>  solution is to fix your build so that it works with "clean 
> verify" on a
>>  'virgin' set of version numbers.
>> 
> 
> To be clear: in a multi-module build, with a root pom, with brand new
> version numbers, you're saying the whole build should run just fine when
> invoked from the root with "clean verify"?
> 
> Just another user trying to do things right,
> Best,
> Laird
> 
>> 
> -- 
> http://about.me/lairdnelson
>

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

Re: Seeking feedback on “Recursive Maven considered harmful”

[Mark Struberg]

how do you know the resource handling is not depending on other jars?


I know this is not perfect, but if you have a bigger project then you have a 
tree of depending modules. And not every module is depending on any other. So 
while a forced 'clean' on _those_ depending modules is more expensive then just 
doing nothing it is still the only practical way. Otherwise the plugins would 
need to know exactly what happened in the other modules. 

Please also note that we do treat external dependencies pretty similar to 
reactor modules once we reach a certain phase in the build lifecycle.


I know that doing this 'clean' is not free of cost, but this is still _way_ 
cheaper than doing a mvn clean install in any case as it is needed right now!


LieGrue,
strub


- Original Message -
> From: Thomas Broyer 
> To: Maven Users List ; Mark Struberg 
> 
> Cc: 
> Sent: Monday, December 17, 2012 3:16 PM
> Subject: Re: Seeking feedback on “Recursive Maven considered harmful”
> 
> On Mon, Dec 17, 2012 at 12:47 PM, Mark Struberg  wrote:
>>  I really like to pick up the work again, but currently busy with graduating 
> another project.
>> 
>>  The next important points to do are
>> 
>>  * inter-project change detection. If you have a dependency to another 
> project which changed, you need to basically do a full build on your 
> depending 
> module. Thus said, if we have this we do _not_ need to rebuild any other 
> modules 
> which do not have such a dependency.
>> 
>>  * making maven-resource-plugin incremential ready. Later on other plugins, 
> but m-r-p is really used a lots and if you have a new config, then you most 
> likely also like to rebuild/retest your project
>> 
>>  * surefire integration. If no dependency got changed and no code/previous 
> stuff got changed, you most probably also do not like to run all the tests 
> again. This could _seriously_ cut down build times!
> 
> DISCLAIMER: I'm over-simplifying things here by only considering Java
> projects, I know it's more complex than that.
> 
> Some of the things above above and in
> https://cwiki.apache.org/MAVEN/incremental-builds.html are kind of
> scary!
> Because one of your dependencies has changed does not mean you have to
> do a "clean": let each plugin decide. For instance, the resources
> plugin doesn't really care what your dependencies are. The compiler
> plugin will use some of them though, and it can simply include them in
> its staleness check.
> 
> Ideally the compiler plugin would track dependencies at the class (or
> file) level. In the example from the wiki, it would store in
> target/maven.status/compiler.status that BeanA2 depends on BeanA and
> thus needs to be recompiled if BeanA has changed. In ModuleB, it could
> be enough to track that BeanA comes from ModuleA and that BeanB thus
> needs to be recompiled if the ModuleA dependency has changed. Because
> we're in a multi-module build though, we might want to track the
> direct dependency to BeanA as ModuleB could be compiled with the
> target/classes of ModuleA, so you could skip recompiling BeanB if only
> BeanA2 has changed. AIUI, IDEs are already doing such dependency
> tracking, and it does not seem to be taking that much time to compute
> the dependency graph and then incrementally update it as files change.
> The compiler plugin also needs to remove BeanA2.class from
> target/classes when I delete BeanA2.java from src/main/java or I
> rename it (and similarly for the resources plugin).
> 
> Similarly, you'd want to track class/files dependencies to only run
> those tests related to the classes that changed. A less ambitious goal
> would, as you propose, only skip running tests altogether when
> nothing's changed, and run all of them otherwise (as today), and that
> would already save all of us a huge amount of build time.
> 
> This is not an easy task though, I know it, I know it cannot be done
> in a matter of days or weeks, but it looks to me like it can be done
> incrementally, one plugin at a time (the wiki also discusses
> properties and profiles, which I hadn't thought about, but it seems to
> me like this is not that different: take the plugin's configuration
> into account when computing the work that needs to be done; the only
> change needed at the core level would be tracking which plugins ran in
> a previous build that won't run in the current one, it could then call
> the plugin's "clean" goal if it exists at the beginning of the 
> build,
> with its previous configuration, and otherwise clean the whole module)
> 
> I might very well miss something obvious here though, as I'm merely
> thinking out loud. Feel free to disregard my statements or contradict
> me, I'm here to learn.
>

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

Re: Seeking feedback on “Recursive Maven considered harmful”

[Mark Struberg]

I really like to pick up the work again, but currently busy with graduating 
another project.

The next important points to do are

* inter-project change detection. If you have a dependency to another project 
which changed, you need to basically do a full build on your depending module. 
Thus said, if we have this we do _not_ need to rebuild any other modules which 
do not have such a dependency.

* making maven-resource-plugin incremential ready. Later on other plugins, but 
m-r-p is really used a lots and if you have a new config, then you most likely 
also like to rebuild/retest your project

* surefire integration. If no dependency got changed and no code/previous stuff 
got changed, you most probably also do not like to run all the tests again. 
This could _seriously_ cut down build times!

LieGrue,
strub




- Original Message -
> From: Stephen Connolly 
> To: Maven Users List 
> Cc: 
> Sent: Monday, December 17, 2012 12:36 PM
> Subject: Re: Seeking feedback on “Recursive Maven considered harmful”
> 
> Current work on Maven compiler plugin version 3.0 is adding support for an
> incremental mode.
> 
> It is a tricky balance to cut, as if incremental mode is too aggressive,
> you compile more than is strictly necessary... and if too lax, you compile
> less than is required and people end up having to run "clean" first 
> again.
> 
> Another issue is that people abuse the "install" hack far more often 
> than
> they should...
> 
> In fact it seems most people's default mode with Maven is to go "mvn 
> clean
> install".
> 
> There are a lot of issues with that, not least being that you are abusing
> the local repository cache.
> 
> Where this really kicks in is when people have made their build to *rely*
> on artifacts being installed in the cache... cue ensuing hilarity when
> using the release plugin... "solved" (if even detected) by people 
> changing
> to clean install... of course 
> the real
> solution is to fix your build so that it works with "clean verify" on 
> a
> 'virgin' set of version numbers.
> 
> One of your points about partial phases actually misses one of the key
> things about Maven that a lot of people have missed... namely that you
> don't have to go all the way.
> 
> The extension of my "install" hack complaint is the 
> "package" hack
> complaint.
> 
> If your build requires you to go as far as the "package" phase, then 
> likely
> you are missing out on doing it right... might not be your fault, may the
> the fault of some plugins you are using... but none the less there are
> things you are missing out on.
> 
> My hope is that, for example, some of the tricks I am applying with the
> jszip.org's maven plugin will enlighten people into the benefits of getting
> your build 'right'... for example
> 
> $ mvn compile jszip:run
> 
> In a multi-module build... now your java classpath is not for the
> **/target/*.jar files but for the **/target/classes directories... so you
> can have your IDE compile the changed classes, and the classpath scanning
> of jszip:run will pick up the changes and reload the servlet container...
> With the background compile feature in for example IDEA 12 (I ack that
> eclipse's webby plugin does similar to jszip:run... some of my tricks were
> picked up from Benjamin) you basically can just write your java and
> javascript code and switch back to the browser, hit reload and see the
> changes...
> 
> If you do "mvn package jszip:run" however the `target/classes` 
> directory
> will have been replaced as the primary artifact by the
> `target/${finalName}.jar` and therefore we are limited to watching for the
> .jar file to be modified... no more live development. Yes I could hack and
> infer the target/classes directory... but that hack would not be the Maven
> way.
> 
> So the phase you invoke depends on your needs.
> 
> You are doing Maven wrong (IMHO) if your entire build cannot work under the
> following incremental behaviours:
> 
> 1. Change all the modules to a 'virgin' version number (one that has 
> never
> been touched before... don't want the local repo or any remote repos
> "helping" us out
> 2. "mvn clean" if you cannot clean a clean fresh checkout on virgin 
> version
> numbers #fail
> 3. "mvn clean generate-sources" if you cannot create all the generated
> source code, your IDE experience will be less than stellar #fail
> 4. "mvn clean compile" if you cannot compile all your production code
> without bundling up jars and stuffing them in the local repo cache, shame
> on you #fail
> 5. "mvn clean test-compile" if you cannot compile all your test code 
> #fail
> 6. "mvn clean package -DskipTests" if those packaged artifacts need to 
> go
> into the local repo cache for subsequent modules to find them, you have a
> subtly broken build #fail
> 7. "mvn clean verify -DskipTests" if you cannot use the release 
> plugin's
> default test of a releaseable artifact on virgin version numbers: #fail
> 
> Note that all these tests are designed to be q

Re: Version ranges not working

[Mark Struberg]

In practice it gets more complicated if you are a framework. The safest way is 
to even change your package name to reflect the API change.

LieGrue,
strub



- Original Message -
> From: Ron Wheeler 
> To: users@maven.apache.org
> Cc: 
> Sent: Sunday, September 30, 2012 7:08 PM
> Subject: Re: Version ranges not working
> 
> Read what I wrote:
> If you are making an artifact that is not upward compatible, you need to 
> prevent people from thinking that they can just up the version number in 
> their GAV and they will get a better version with bugs fixed.
> You are in fact giving them a new artifact that will not only NOT fix 
> bugs but will give the victim NoSuchMethods or NullPointers (if scope is 
> "provided") in code that would work with the previous artifact.
> 
> I don't care if you use the version number as part of the new ArtifactID 
> or just add the word "nouveau" at the front of the ArtifactID.
> Just make sure that you change the G or the A and not just the V.
> 
> Ron
> 
> On 29/09/2012 4:50 PM, Mark Derricutt wrote:
>>  Wait,
>> 
>>  You're suggesting we starting encoding VERSION NUMBERING into the 
> artefact NAME now? Isn't that just as bad, if not worse than the abuse of 
> classifiers we already see out there?
>> 
>>  We have the exact same issue being discussed here, and also as mentioned by 
> others use OSGi. One of the key things to think of in all these situations to 
> also let your artefacts work FOR you.
>> 
>>  1) Separate out APIs from implementations - two artefacts
>>  2) Users depend ONLY on API - NEVER implementations - mock those 
> implementations for testing, or have a third "fake/test" impl.
>>  3) Use composite artefacts for grouping common dependencies - a POM only 
> artefact with dependencies, i.e. a testing pom that deps on testng, 
> fest-assert 
> etc. etc.
>>  4) Often its only really the packaging/distribution that really needs the 
> range to be resolved so maybe we should enhance the assembly plugin, or some 
> other new packaging plugin.
>> 
>> 
>> 
>> 
>>  On 29/09/2012, at 8:21 AM, Ron Wheeler 
>  wrote:
>> 
>>>  Not acceptable. If a developer is not going to provide upward 
> compatibility, then they should change the Artifact id to be sure that no one 
> gets hurt because of the laziness or lack of thoughtfulness or just plain bad 
> design of the older version.
>>>  Major versions are not incompatible in most libraries.
>>>  Hibernate is a good example where the developers realized that version 
> 3 was completely different from versions.
>>>  If they wanted to have reasonably method names without the danger of 
> people getting hurt by trying to run code written to version 2 specs against 
> version 3, they had to rename the artifacts.
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> 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: Version ranges not working

[Mark Struberg]

I thought about mathematical ranges as well, and the outcome for me personally 
that a strict mathematical time vector interpretation makes no sense for maven.


You have a library in version 1.7.0 which fits your project.

Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary 
incompatible change.

But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. 

Also: for most dependencies you only like to get released versions via your 
version range. But as I read here some use this internally as well and like to 
get SNAPSHOTS resolved. 

What about simply writing up what people like to have and then implement a new 
mechanism?
I could even think about regexp based versioning...

LieGrue,
strub




- Original Message -
> From: Hervé BOUTEMY 
> To: Maven Users List 
> Cc: 
> Sent: Saturday, September 29, 2012 5:06 AM
> Subject: Re: Version ranges not working
> 
> yes, https://jira.codehaus.org/browse/MNG-3092 is still here
> 
> I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we 
> do 
> so, it's not a *range* any more but a range + a filter
> (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english")
> 
> and actual discussion helps me dig into other ideas that could be useful: 
> IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and 
> beta too, no?
> But I'm not sure about the use case (and "Guide to using version 
> ranges" still 
> needs to be written: https://jira.codehaus.org/browse/MNG-1368)
> I understand that when a library is at 1.9 and someone needs old 1.8-, he 
> implictely wants releases, not alpha nor SNAPSHOTS
> But if 1.8 is still not out, and there is still work on 1.7.x, we need to 
> accept *latest* 1.7.x whatever its maturity level is
> 
> 
> Really , excluding version from a mathematical range is another operation 
> that 
> needs some specification and probably something more expressive than [min,max]
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit :
>>  I find this topic interesting for a couple of reasons.  I was one of the
>>  original posters of this topic and created some of the relevant JIRA issues
>>  regarding it.
>> 
>>  However one of the problems is that since this issue was never fixed...and
>>  sadly seems never will be...we had to abandon the use of version ranges.  I
>>  do not agree they are a bad idea.  I think they could have been a very
>>  useful feature if implemented as originally proposed.
>>   (The fundamental problem was that they did not exclude SNAPSHOTS as
>>  originally intended/stated.)
>> 
>>  Effectively we had to work around the lack of version ranges by just
>>  building against SNAPSHOTS instead (I'm talking about internal code 
> here).
>>   So effectively the SNAPSHOT became our version range.  One of the problems
>>  of this approach is now I have to toggle between going offline/online if I
>>  don't want to accept new updates since it will be changing on a regular
>>  basis.  Using version ranges would have been a more elegant solution as it
>>  would give me more control over what versions I depend on during
>>  development.
>> 
>>  Because it wasn't fixed and we had to do the workaround I have not been
>>  close to this issue anymore...its been like 5 years or more.  But the short
>>  answer is it should be fixed and it can/could be useful as some have
>>  indicated in this discussion.
>> 
>>  -Dave
>> 
>>  On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler 
> >  > wrote:
>>  > 
>>  > On 28/09/2012 3:17 AM, Jesse Long wrote:
>>  >> Without version ranges, how do I write a library that works with 
> SLF4J
>>  >> version 1.5.*, but does not work with SLF4J 1.6.*?
>>  >> 
>>  >> Do I depend on, say, version 1.5.11? Then when a user depends on 
> my
>>  >> library, and on slf4j-api directly, specifying slf4j-api version 
> 1.6.0 in
>>  >> his pom, Maven will link in 1.6.0. So that is pretty useless to 
> me. If I
>>  >> find a way to enforce version 1.5.11. Then I am loosing the 
> ability to
>>  >> upgrade to any future version 1.5.*.
>>  >> 
>>  >>  I am not sure how version ranges will help you in this case.
>>  > 
>>  > Your mythical user is overriding your version 1.5.* with 1.6.* so he 
> will
>>  > be in trouble using your library regardless of what you put in your
>>  > dependency.
>>  > 
>>  > If your library is clearly documented as not being compatible with
>>  > versions after 1.5.*, then the user is responsible for making sure 
> that
>>  > nothing brings in a later version of slf4j.
>>  > 
>>  > You had better write a big note about your restriction since most of 
> us
>>  > will just put an exclusion on your transitive dependency  for slf4j 
> and
>>  > run
>>  > with the version that we want.
>>  > 
>>  > There are not many good libraries that are not upwards compatible and 
> it
>>  > is generally safe to run with the latest version of everything.
>>  > The good library authors will change the artifact name if the new 
> version
>>  > 

Re: How to exclude transitive dependencies from war?

[Mark Struberg]

I have a similar configuration in my project. 

It is an EAR project with lots of WARs on their own. The goal was to provide a 
way to be able to debug/develop the WARs standalone e.g. via mvn tomcat7:run. 
In this situation you need all your dependencies (even platform JARs like 
openwebbeans, myfaces and openjpa) in your WEB-INF/lib folder. But those libs 
should not get packaged when building the final EAR.

I ended up with an own 'ear' profile with has war-excludes set:



    
    ear
    
 

    
    org.apache.maven.plugins
    maven-war-plugin
    
    
    ${war.excludes}
    

the war.excludes properties is maintained in a central location. Please note 
that the war.excludes contains a list of file names and not packages. 

E.g. WEB-INF/lib/openwebbeans-*,WEB-INF/lib/myfaces-api-*, ...



LieGrue,
strub



>
> From: Vincent Latombe 
>To: Maven Users List  
>Sent: Friday, September 28, 2012 6:27 PM
>Subject: Re: How to exclude transitive dependencies from war?
> 
>Hello,
>
>I believe there is now a skinny war option in the ear plugin that could
>help you to handle this case. I never used it so I cannot really tell you
>more about it.
>
>Another option would be to have 2 profiles to build your war. One with all
>dependencies provided by the ear marked as provided, and another one with
>the same dependencies with compile/runtime scope.
>
>Again another option would be to exclude dependencies at package time (in
>the war plugin configuration)
>
>Hope this helps,
>
>Vincent
>Le 17 sept. 2012 21:10, "David Hoffer"  a écrit :
>
>> I need to package a war so that it can be optionally included in a ear
>> deployment, put I can't just mark the ear level dependencies as
>> provided because I do need the full war doing development work and
>> running GWT hosted mode.
>>
>> I've followed this link
>>
>> http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html
>> regarding how to set the dependency as optional, which seems like it
>> might be the right solution, as I want the full war in the current
>> project but when used as an ear dependency I want it to exclude a
>> dependency (and all its transitive dependencies).
>>
>> However its not working that way...if I set the artifact via:
>>
>> 
>>             com.foo
>>             bar
>>             compile
>>             true
>> 
>>
>> It removes just the artifact bar from the war but leaves in the war
>> all it's transitive dependencies, which is not expected.  How can I
>> also exclude it's transitive dependencies?  This point is key as the
>> logic provided by the ear is significant and probably has 100 or more
>> jars...no way to know what they all are and that can change too.
>>
>> -Dave
>>
>> -
>> 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: What does the "tag" parameter for release:branch do?

[Mark Struberg]

+1 Laird, that is for sure the best thing. I guess we need to clean up a few 
things in this area.

An attempt for a small historical summary:

*  was useful in CVS (not in all operations but in most)

*  is almost useless in SVN as you get a different directory for branches 
and tags
* due to SVN being the dominating SCM for most of the last decade, we didn't 
take much care about 
*  is useful again for a lot of the newer DSCMs which handle tags and 
branches more like CVS than SVN.

and now we need to clean up the mess ;)
I personally think it will not be that hard to do. 

strub



- Original Message -
> From: Laird Nelson 
> To: Maven Users List 
> Cc: 
> Sent: Friday, September 28, 2012 4:47 PM
> Subject: Re: What does the "tag" parameter for release:branch do?
> 
> On Fri, Sep 28, 2012 at 12:34 AM, Anders Lindgren <
> anders.lindg...@cinnober.com> wrote:
> 
>>  I would guess that it is used by SCM's like CVS which takes an existing
>>  tag as base for a new branch.
>>  The explanation could be better as many of the other parameters
>>  describes SVN specific usage.
>> 
> 
> Thanks; I guess I'll just go dig through the source.
> 
> Best,
> Laird
> 
> -- 
> http://about.me/lairdnelson
> 

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

Re: Version ranges not working

[Mark Struberg]

Sad but true. 

An example:

There are projects which use "1.0-MR1" as "Milestone Release"

which gets released _before_ 1.0 final.

And there are other projects which use "1.0-MR1" as "Maintenance Release"

which obviously gets released _after_ 1.0 final.

Anything else than pure numbers is a candidate to be broken somehow.


LieGrue,
strub

- Original Message -
> From: Stephen Connolly 
> To: Maven Users List 
> Cc: 
> Sent: Friday, September 28, 2012 1:03 AM
> Subject: Re: Version ranges not working
> 
> My experience with versions-maven-plugin would show different, but each to
> their own
> 
> On 27 September 2012 23:56, Paul French  wrote:
> 
>>  I have to disagree. Version ranges are very useful to us especially with
>>  artifacts we control where we use semantic versioning and api analysis to
>>  enforce this.
>> 
>>  Artifacts we don't control the versioning of e.g SLF4J we nail down the
>>  version we use.
>> 
>>  Our product POM's can have 100's of version ranged artifacts
>> 
>>  If we could plugin a version range class into maven (maven would ship with
>>  a version range class with the rules it uses now), at least I would then
>>  have a choice to replace it with an implementation I'm happier with.
>> 
>>  Anyway it works for us as it is now, so I'm not going to lose any sleep
>>  over it.
>> 
>>  Cheers
>> 
>> 
>>  On 27/09/2012 23:36, Stephen Connolly wrote:
>> 
>>>  Well that is a recipe for disaster. rules only make sense within the 
> scope
>>>  of the artifacts they apply to.
>>> 
>>>  This is kind of why version ranges are next to useless from a practical
>>>  PoV
>>>  anyway
>>> 
>>>  On 27 September 2012 23:05, Paul French  
> wrote:
>>> 
>>>   I would only want the same version rules applied to all artifacts, not 
> on
  a per artifact basis, that would be a nightmare! I understand that 
> people
  who produce artifacts have their own versioning rules. However we 
> can
  take
  that into account in our version ranging.
 
  Usually for 3rd party artifacts we have a very narrow version range 
> since
  we cannot trust the producer of that artifact not to break their 
> current
  API in later versions unless they support semantic versioning.
 
 
  On 27/09/2012 22:29, Stephen Connolly wrote:
 
   when is that class applied?
> 
>  each dependency would have its own comparator, as each 
> dependency has
>  its
>  own versioning rules.
> 
>  and then don't start on epoch's (i.e. where the 
> versioning rules change
>  from under your feet mid sequence
> 
>  It's tempting... but dangerous... the closest I have come 
> up with is the
>  rulesets hack from versions-maven-plugin @ mojo... but even 
> that has
>  issues... hence why I haven't pushed it further.
> 
>  -Stephen
> 
>  On 27 September 2012 22:19, Paul French 
>  wrote:
> 
>    Okay I see the problem.
> 
>>  How about allowing a user to plugin a Version class that 
> implements
>>  Comparator
>> 
>>      class MavenVersion implements 
> Comparable
>>      {
>>        public int compareTo(MavenVersion o)
>>        {
>>          // your implementation
>>        }
>>      }
>> 
>>  Then we can all do whatever we need.
>> 
>> 
>>  On 27/09/2012 21:40, Hervé BOUTEMY wrote:
>> 
>>    I understand that many people get caught
>> 
>>>  But what do you expect from [1.7,1.8]?
>>>  And [1.7,1.8-beta)?
>>> 
>>>  The actual semantic is pure mathematical range, 
> including or excluding
>>>  an
>>>  extreme
>>> 
>>>  since 
> 1.8-alpha<1.8-beta-<1.8-rc<1.**8-SNAPSHOT<1.8, it's pure
>>>  math
>>> 
>>> 
>>>  IMHO, anything that doesn't conform mathematical 
> range will have some
>>>  unexpected behaviour sometime
>>> 
>>>  Yes, people need to learn that they usually want
>>>  [1.7,1.8-alpha-SNAPSHOT)
>>>  if
>>>  they want to be precise. Or approximations: 
> [1.7,1.8-a), [1.7,1.7.999]
>>>  Or we need to create another notation and define its 
> semantics
>>>  precisely
>>> 
>>>  Regards,
>>> 
>>>  Hervé
>>> 
>>>  Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit 
> :
>>> 
>>>    +1
>>> 
  I agree with Jesse.
 
  A version range like [1.7,1.8) should exclude any 
> artifact that
  starts
  with 1.8
 
  Then maven (or aether) would respect semantic 
> versioning rules.
 
  We use version ranges/semantic versioning and API 
> analysis to ensure
  our
  artifacts are versioned correctly. Sometimes we get 
> caught out by
  what
  Jesse outlined below.
 
  On 27/09/2012 15:51, Stephen Connolly wrote:
 
    On 27 September 2012 14:41, Jesse Long 
>  wrote:
 
>    Dear Maven Commu

Re: How to put a dependency in the classpath BEFORE jre.jar?

[Mark Struberg]

I did not read through the whole thread, so maybe I missed (sorry for that).

Afaik maven plugins use a different ClassLoader hierarchy than you might expect.
Most frameworks use ParentClassLoaderFirst, but maven afaik uses 
ClientClassLoaderFirst.

Which means it's perfectly fine to to put a javax.* dependency in your plugin 
classpath. The only thing which is not allowed is to overwrite native SE stuff.

LieGrue,
strub




- Original Message -
> From: Benson Margulies 
> To: Maven Users List 
> Cc: 
> Sent: Tuesday, September 25, 2012 8:08 PM
> Subject: Re: How to put a dependency in the classpath BEFORE jre.jar?
> 
> Markus,
> 
> If you want to join in on the fun of the development community, please
> join us on the dev list. As you've heard on this thread, your
> particular concern smacks into a messy conundrum about our desire to
> avoid breaking other people's tools that read poms -- no matter how
> poorly coded. However, there is a design in progress, it needs more
> refinement, and mostly it will need people to actually code it.
> 
> --benson
> 
> -
> 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: NullPointerException on Maven Compile

[Mark Struberg]

Hi Clebert. 

I'm currently working on m-compiler-p 2.6 and will give it a look.

LieGrue,
strub




- Original Message -
> From: Clebert Suconic 
> To: users@maven.apache.org
> Cc: 
> Sent: Thursday, September 13, 2012 10:56 PM
> Subject: NullPointerException on Maven Compile
> 
> We have recently upgraded mvn compile on HornetQ, a
> Message-oriented-middleware from RedHat,
> 
> 
> and we are now facing a NullPointerException on mac computers, when we
> upgrade mvn-compiler to 2.5. It all works fine with 2.3.1, and it's funny
> that only fails on my mac.
> 
> * https://gist.github.com/3717257
> 
> 
> If there's anyone available to take a look, you can download my repo at:
> 
> git://github.com/clebertsuconic/hornetq.git
> cd hornetq
> git checkout mvn-upgrade-fails
> 
> or you can view it here:
> https://github.com/clebertsuconic/hornetq/tree/mvn-upgrade-fails
> 
> 
> 
> *
> Here is the NPE I"m getting (with mvn -X)
> 
> [INFO] Compiling 50 source files to
> /work/hornetq/hornetq/hornetq-commons/target/classes
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] error: java.lang.NullPointerException
> [INFO] 1 error
> [INFO] -
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 2.935s
> [INFO] Finished at: Thu Sep 13 15:13:53 CDT 2012
> [INFO] Final Memory: 9M/81M
> [INFO] 
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> (default-compile) on project hornetq-commons: Compilation failure
> [ERROR] error: java.lang.NullPointerException
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> (default-compile) on project hornetq-commons: Compilation failure
> error: java.lang.NullPointerException
> 
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>     at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>     at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>     at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>     at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.CompilationFailureException:
> Compilation failure
> error: java.lang.NullPointerException
> 
>     at 
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:729)
>     at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
>     at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>     at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>     ... 19 more
> [ERROR]
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>

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

Re: Arguments for Maven vs. Gradle

[Mark Struberg]

Oki, I confess... hang me now

"line on the left, only one cross each person"



;)

LieGrue,
stru



- Original Message -
> From: "Thiessen, Todd (Todd)" 
> To: Maven Users List ; Mark Struberg 
> 
> Cc: 
> Sent: Tuesday, September 11, 2012 2:35 PM
> Subject: RE: Arguments for Maven vs. Gradle
> 
>>  "With great power comes great responsibility" (Starwars? Kung-fu 
> panda?
>>  not sure anymore :)    
> 
> Spiderman. Come on now... You get points for maven knowledge but minus points 
> for missing the Spiderman reference.  Three cheers for Stan Lee ;-).
> 
> -
> 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: Arguments for Maven vs. Gradle

[Mark Struberg]

Gradle allows to hack something much quicker. In Maven you would need to write 
a plugin. 

Otoh I've seen a Gradle project which went from great to barely maintainable in 
almost under a year.
Just let a few juniors touch the build and you are doomed pretty quickly.
The approach of gradle is not new. Check buildr [1] which does almost the same 
but in ruby instead of groovy. And I think it even predates gradle.
That was great too in the beginning, but after 3 years the projects were 
insanely broken and we moved them back to maven again.

"With great power comes great responsibility" (Starwars? Kung-fu panda? not 
sure anymore :)

LieGrue,
strub


[1] http://buildr.apache.org/




- Original Message -
> From: Paul King 
> To: Maven Users List 
> Cc: 
> Sent: Tuesday, September 11, 2012 11:30 AM
> Subject: Re: Arguments for Maven vs. Gradle
> 
> You will have to make your own assessment but most new projects I see in my
> customer base are moving over to gradle. It offers the same convention over
> configuration advantages of Maven but with some flexibility if you need it,
> plus a whole swag of benefits that are gradle specific. The dependency
> management story is practically identical to the maven world.
> 
> Cheers, Paul.
> 
> On Tue, Sep 11, 2012 at 4:28 PM, Baptiste MATHUS  wrote:
> 
>>  (Disclaimer: I only know Gradle from outside. I never used it more than 2
>>  minutes, but I read some things about and saw a prez at our JUG.)
>>  Gradle has a very different approach: where Maven values sometimes not much
>>  flexibility at first sight (to improve build genericity, as already said),
>>  Gradle lets you change anything you want. The good thing is that Gradle
>>  comes with some standard process if you want to go Maven-style (meaning the
>>  standard fits your needs). But then you can plug whatever you want, the way
>>  you want, anytime you want (using Groovy scripting code).
>> 
>>  By the way, that last statement is the kind of things that makes Gradle
>>  appear to Maven-fans as no-good. In fact, for the record, Maven 1 was using
>>  a scripting language (Jelly), and being able to clutter your build file
>>  with scripts is just a bad idea.
>> 
>>  About Maven coordinates, yes Gradle can use them. I seem to remember
>>  they're actually using Ivy as their dependency management tool.
>>  By the way, you can disable transitive dependencies, etc.
>> 
>> 
> http://gradle.org/docs/current/userguide/dependency_management.html#defineConfiguration
>> 
>>  Cheers
>> 
>>  2012/9/10 KARR, DAVID 
>> 
>>  > > -Original Message-
>>  > > From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
>>  > > Sent: Sunday, September 09, 2012 4:43 PM
>>  > > To: users@maven.apache.org
>>  > > Subject: Re: Arguments for Maven vs. Gradle
>>  > >
>>  > > Moving from Ant to Maven is a change of attitude.
>>  > > You are right that Maven does make builds much more uniform.
>>  > > Once a project is set up, the next guy to work on it only has to 
> write
>>  > > code and add dependencies, the rest of the environment is laid 
> out.
>>  > >
>>  > > Never heard of Gradle so I can not compare them.
>>  > >
>>  > > Maven has a huge following and almost any library that you want 
> to use
>>  > > has a Maven distribution available at Maven Central or in a 
> public repo
>>  > > that you can connect to .
>>  > > Saves a lot of grief.
>>  > >
>>  > > If you go with Maven, get your own repo set up before you unleash 
> the
>>  > > developers.
>>  >
>>  > Thanks.
>>  >
>>  > Not that I disagree with your overall conclusion, but I would point 
> out
>>  > that Gradle makes it easy to specify dependencies through Maven
>>  > coordinates.  I would assume that means it also handles transitive
>>  > dependencies, but I'm not sure.  It's a good idea to 
> "know your enemy",
>>  not
>>  > that I consider Gradle an "enemy" in any way.
>>  >
>>  > > On 09/09/2012 5:20 PM, KARR, DAVID wrote:
>>  > > > At the risk of starting a flame war, what are some arguments 
> for
>>  > > Maven vs. Gradle?
>>  > > >
>>  > > > This is in the context of a change and risk-averse 
> organization that
>>  > > currently has a large Ant build, although with some associated 
> Maven
>>  > > builds.
>>  > > >
>>  > > > I see the advantages of Gradle as a much better Ant, but I 
> would be
>>  > > concerned about losing the advantages of Maven, like better 
> integrated
>>  > > tool support.
>>  > > >
>>  > > > One of the disadvantages of Gradle is the same as Ant, which 
> is that
>>  > > it's very easy to have two people do similar things in a 
> completely
>>  > > different way.  Gradle makes it easier to reuse things, but it 
> doesn't
>>  > > seem like it nudges you that hard in that direction.
>>  > > >
>>  > > > I can see the possibility of calling Groovy from Maven, but 
> having
>>  > > that be Gradle code would require the Gradle runtime, and I 
> don't see a
>>  > > "Gradle Maven plugin" yet (although I believe I've 
> seen a "Maven Gradle

Re: Creating one big jar in Maven?

[Mark Struberg]

If your goal is to have only one fat jar which contains all stuff and is 
executable then you can also try the onejar-maven-plugin
http://code.google.com/p/onejar-maven-plugin/

LieGrue,
strub




- Original Message -
> From: Nikolay Rychkov 
> To: Maven Users List 
> Cc: 
> Sent: Sunday, August 26, 2012 2:40 AM
> Subject: Re: Creating one big jar in Maven?
> 
> I use configs
>   
>                 
> 
>                 
>                     
> 
> 
>                     
>                     
>                         
> 
> 
>                         
>                     
>                 
>                 
>                     
>                         
>                         
>                             
>                         
>                     
>                 
>             
> 
>             
>             
>             
>             
>             
>             
>             
>             
>             
>             
>             
>             
>             
> 
> 
>             
> 
>             
>             
>             
>             
>             
>             
> 
> 2012/8/25 Aliaksei Lahachou 
> 
>>  Hi,
>> 
>>  take a look on maven-shade-plugin. I believe it's simpler if you only 
> need
>>  to build an uber-jar.
>> 
>> 
>>  Regards,
>>  htfv (Aliaksei Lahachou)
>> 
>> 
>>  On Sat, Aug 25, 2012 at 7:19 AM, Barrie Treloar 
>>  wrote:
>> 
>>  > On Sat, Aug 25, 2012 at 5:44 AM, jpyork 
> 
>>  wrote:
>>  > > Hello I am a bit new to Maven and have taken over a build from a
>>  departed
>>  > > employee that uses Maven.  The issue is that he over complicated 
> it
>>  with
>>  > vb
>>  > > scripts and other items, but I have finally got the project to 
> build
>>  with
>>  > > just executing a parent POM file.  The issue I have now is that I 
> have
>>  6
>>  > > internal modules that we build and they all produce jars in 
> different
>>  > > locations, but I want to be able to bring them all together in 
> one
>>  > location
>>  > > and then package them all together for one big jar file.  I have 
> been
>>  > adding
>>  > > things to the chile POM's without success.
>>  > >
>>  > > Anyone got a way to do this?
>>  >
>>  > http://lmgtfy.com/?q=one+big+jar+maven
>>  >
>>  > Look at the assembly plugin.
>>  >
>>  > -
>>  > 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: Using scope in dependencyManagement: good idea or bad?

[Mark Struberg]

I sometimes use this for libraries (like e.g. openwebbeans-impl) which I 
normally only have a runtime dependency for (generally defined via 
dependencyManagement). 


But in some cases you need to access some internal details. Usually I move 
those parts to some 'utility' module which then has a compile time dependency 
to the needed library.


LieGrue,
strub



- Original Message -
> From: "Thiessen, Todd (Todd)" 
> To: Maven Users List 
> Cc: 
> Sent: Friday, June 1, 2012 5:20 PM
> Subject: RE: Using scope in dependencyManagement: good idea or bad?
> 
> +1 here. I find it valuable to changing scope to provided.
> 
>>  -Original Message-
>>  From: Wayne Fay [mailto:wayne...@gmail.com]
>>  Sent: Friday, June 01, 2012 10:53 AM
>>  To: Maven Users List
>>  Subject: Re: Using scope in dependencyManagement: good idea or bad?
>> 
>>  > the subject say it all: Is declaring scopes in the
>>  dependencyManagement
>>  > section of your parent POM a good idea or a bad idea?
>> 
>>  Unless you are employing an approach wherein all of those deps will be
>>  scope provided [because you are providing them in the application
>>  server's shared libs folder], I think it is a bad idea.
>> 
>>  So I guess specifically for provided-scoped things, I support it, but
>>  not for any others.
>> 
>>  Wayne
>> 
>>  -
>>  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
> 

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

Re: command to build the project using maven 1.1

[Mark Struberg]

do you already have all the stuff (jar, war, ear) in multiple modules?
Or did you script it with jelly yourself?


How is your project structure looking today?

Any chance you can upgrade to mvn-3.0.4? maven-1.1 is pretty old already ...


LieGrue,
strub


- Original Message -
> From: Gunachandra 
> To: users@maven.apache.org
> Cc: 
> Sent: Thursday, May 24, 2012 10:41 AM
> Subject: command to build the project using maven 1.1
> 
> Hello Everybody,
> 
> I am using maven 1.1 for building my project. My Project is separated to
> jar,war and ear. Because i am deploying my project using WAS server. can
> anyone please tell me how to build war and ear in different environment. For
> building jar i used this command : maven jar:install.
> 
> Thank you in advance.
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/command-to-build-the-project-using-maven-1-1-tp5709631.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> 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: Memory Leak?

[Mark Struberg]

It could also be a proxy problem of course. How is guice doing proxies? 

Proxies are also loaded via the ClassLoader and consume perm gen space.


LieGrue,
strub



- Original Message -
> From: Stuart McCulloch 
> To: Maven Users List 
> Cc: 
> Sent: Saturday, May 12, 2012 11:36 AM
> Subject: Re: Memory Leak?
> 
> On 12 May 2012, at 07:32, Hilco Wijbenga wrote:
> 
>>  On 11 May 2012 22:47, Anders Hammar  wrote:
>>>  This is not uncommon for large multi-module builds. You need to
>>>  increase the memory available for Maven, such as the heap depending on
>>>  the error you're getting.
>>>  Do this by setting the MAVEN_OPTS env variable.
>> 
>>  I know, it is already getting 2GB. I can't set it any higher (Maven
>>  refuses to even start then).
> 
> You might be running out of PermGen space - this is a separate heap in the 
> HotSpot JVM used for classes, etc. Normally the default PermGen limit is ok, 
> but 
> can become an issue when running large apps or doing lots of code generation 
> / 
> compilation. The other thing is that bumping the main heap size doesn't 
> change the default PermGen limit - instead you need to use something like:
> 
>    -XX:MaxPermSize=256m
> 
> https://cwiki.apache.org/MAVEN/outofmemoryerror.html
> 
>>>  My experience is that this is mainly due to the plugins being used in
>>>  the build, not Maven core. Are you using Maven 3? Maven 3 core has a
>>>  smaller memory footprint than Maven 2.
>> 
>>  Maven 3.0.3. Should Maven not simply release plugins (and the memory
>>  they use) between module builds?
> 
> IIRC the Maven plugin manager should release mojos after each execution - of 
> course this depends on the plugin not having a memory leak involving static 
> members, which can keep memory around until the classloader is unloaded 
> (which 
> can take longer depending on other references). Also if you're hitting the 
> PermGen limit then it's more about the amount of classes and interned 
> strings you're loading rather the amount of objects being created.
> 
>>  -
>>  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
>

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

Re: Maven 3.0 and EJB 2.0 or 1.0

[Mark Struberg]

Are you seriously still using EJB-1.0? The crap which instantly caused lots of 
people puking back in 1999?

I'm aware that a few poor developers still need to clean up the mess in old 
projects, but is there even a supported container for those things?

I think EJB-3.0 got introduced in early 2006 - and that's already quite some 
time ago. 

Which target container are you using? It might be much easier to just update to 
at least EJB-3.0. I doubt there is any _maintained_ container available who has 
only EJB-1.x support...

LieGrue,
strub





- Original Message -
> From: sarmahdi 
> To: users@maven.apache.org
> Cc: 
> Sent: Tuesday, April 24, 2012 10:49 AM
> Subject: Maven 3.0 and EJB 2.0 or 1.0
> 
> Hello guys,
> 
> How can I mavenize a project that uses older versions of EJB like 1.0 or
> 2.0. I know the plugin does support EJB 2.0+ but it has limited
> capabilities. How did people work around this issue. I am sure there must be
> a lot of projects that used EJB 2.0 at least if not 1.0 as Maven has been
> around for 10 years almost now. 
> 
> The current ejb plugin can only compile EJB project into a normal JAR but it
> is not some thing that can be deployed on WAS 7.0 as an EJB JAR. it does not
> generates stubs and skeletons. 
> 
> I would really like to know, What did maven users do for their EJB 1.0
> projects?
> 
> Thanks for any replies.
> 
> Syed Mahdi.
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Maven-3-0-and-EJB-2-0-or-1-0-tp5661362p5661362.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
> 
> -
> 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: Help again for working with release:plugin

[Mark Struberg]

Hi!

Please note that this isn't as crucial as it sounds here.

The only thing that you might add is a simple pom.xml which just contains the
 

section including all your child projects. 

If you don't like to do it then you can also just add  sections to each 
and every of your projects...

There is nothing here what maven does wrong! It is just that you didn't follow 
the convention, thus you need to configure that stuff yourself. ...like you 
would need to configure this stuff manually in all other build systems I know...

LieGrue,
strub



- Original Message -
> From: Manfred Moser 
> To: users@maven.apache.org
> Cc: 
> Sent: Tuesday, February 21, 2012 1:04 AM
> Subject: Re: Help again for working with release:plugin
> 
>T orsten,
> 
> While you are right that you can do this setup using relative paths and 
> so on like Ansgar told you rightly and you have discovered yourself.. it 
> wont work nicely.
> 
> If you are fighting Maven you are wasting a lot of time and effort. Just 
> refactor the build to follow maven conventions.. it will be way easier 
> to deal with it..
> 
> manfred
> 
> On 12-02-20 02:48 PM, Dipl.-Ing. Torsten Liermann wrote:
>>  Hi,
>> 
>>  you are right, but that was not my decision. Maven work with this
>>  configuration, relative pathes to the child modules is sufficiently
>> 
>>  
>>     ../child1
>>     ../child2
>>     ...
>>  
>> 
>>  Now I must see, if is it possible, to give the scm commands a working 
> directory.
>> 
>>  Greetings
>>  Torsten
>> 
>>  On Mon, 20 Feb 2012 22:22:13 +0100
>>    Ansgar Konermann  wrote:
>>>  Hi Torsten,
>>> 
>>>  Am 20.02.2012 22:02, schrieb Dipl.-Ing. Torsten Liermann:
  My parent pom is on the same level as the children poms
>>>  If you mean "they're in the same directory": this is a 
> configuration
>>>  error. Maven is not designed to work with this setup.
>>> 
>>>  Please configure your project to follow Maven directory layout
>>>  conventions (i. e. put child modules in subdirectories and put the
>>>  pom.xml of each submodule in the corresponding directory).
>>> 
>>>  If you cannot use Maven conventions at all for some reason, it's 
> best to
>>>  choose a different tool.
>>> 
>>>  Best regards
>>> 
>>>  Ansgar
>>> 
>>>  -
>>>  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
>> 
> 
> 
> -
> 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: problem scm in superPOM

[Mark Struberg]

yup, there is already a maven model bug open for it.

Originally this behaviour got introduced as 'fix' for SVN a lng time ago.
But you only need this if you like to do sparse releases anyway.
In that case please just duplicate the  section to your child poms as well 
for now.


LieGrue,
strub



- Original Message -
> From: Stephen Connolly 
> To: Maven Users List 
> Cc: 
> Sent: Monday, February 20, 2012 11:38 AM
> Subject: Re: problem scm in superPOM
> 
>T hey are special elements. if inherited, the artifactId is appended...
> you will just have to write each one in each module
> 
> 2012/2/20 José Manuel Prieto :
>>  Hi,
>> 
>>  I try configure to scm (for mvn release:prepare release:perform ) in my
>>  enterprise superPOM. But I have a problem.
>> 
>>  mySuperPom.xml (pom.xml)
>>   
>> 
>  scm:git:ssh://git@192.168.1.18:/home/git/proyectos/
>>  .git
>>   
>> 
>>  
>>  ${git.url}${project.name}${dot.git}
>>   ${git.url}${project.name}${dot.git}
>>  ${git.url}${project.name
>>  }${dot.git}
>>   
>> 
>>  myPom.xml (pom.xml)
>>  
>>   nasa_cierrestaquillasexportacion
>>   
>> 
>>  myEffectivePOM.xml (pom.xml)
>>   
>>   scm:git:ssh://git@192.168.1.18:
>> 
> /home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion
>>   scm:git:ssh://git@192.168.1.18:
>> 
> /home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion
>>  scm:git:ssh://git@192.168.1.18:
>> 
> /home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion
>>   
>> 
>>  The question is, why put at the end?:
>>  scm:git:ssh://git@192.168.1.18:
>> 
> /home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion
>>  instead of:
>>  scm:git:ssh://git@192.168.1.18:
>>  /home/git/proyectos/nasa_cierrestaquillasexportacion.git
>>  why add /nasa_cierrestaquillasexportacion?
>> 
>>  If I put scm in myPom.xml all is correct.
>> 
>>  Thanks
>>  Jose Manuel Prieto
> 
> -
> 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: Maven 3, _maven.repositories and *lastUpdated

[Mark Struberg]

> If Maven said something like:  "The {GAV} artifact was found in your local
Such kind of warning would make a lot of sense. Could you please file an issue? 
txs!

> Was there some reason why only the repository "id" 

I guess it's mainly because of the 'mirror' sections to allow repo managers.

Also in company environments it sometimes happens that server URLs get moved 
but the content actually remains the same.

I fear there is no perfect solution. If e.g. 2 projects use the same repo-id 
and point to different URLs, then this would also cause inconsistency. But I 
think this problem is more theoretic than practically relevant. Lets keep it 
with Simon&Garfunkel: there are 50 ways to leave your lover (or crash your 
system)...


LieGrue,
strub



- Original Message -
> From: Mark Derricutt 
> To: Maven Users List ; Mark Struberg 
> 
> Cc: 
> Sent: Sunday, October 23, 2011 11:03 PM
> Subject: Re: Maven 3, _maven.repositories and *lastUpdated
> 
> Wait - your not SERIOUSLY calling out Maven Central as being a quality
> repository?  It's certainly much better now with the excellent work
> oss.sonatype.org is providing, but there's still so much broken meta-data
> and missing jars and cruft floating around central.
> 
> Back to the topic tho - I wouldn't so much be opposed to this behavior if
> maven actually told the user this is whats happening, rather than its
> current behavior of just saying "artifact not found".  I've had 
> numerous
> people question their sanity on IRC, around work and elsewhere the confusion
> of artifacts being in their local repository, but not being found.
> 
> If Maven said something like:  "The {GAV} artifact was found in your local
> repository, but came from the undeclared repository "xxx", either 
> configure
> this in your pom, or in your "yyy" mirror."
> 
> Was there some reason why only the repository "id" is stored in the
> _maven.repositories file, and not the URL to it?  If two projects had
> "jboss", and "JBoss" as ids pointing to the same URL, 
> I'd expect them to
> work, but I suspect because maven doesn't track that level, then it
> wouldn't?
> 
> Mark
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven 
> Wilson,
> Porcupine Tree
> 
> On Mon, Oct 24, 2011 at 6:52 AM, Mark Struberg  wrote:
> 
>>   Another problem did arise with the java.net maven repo and other repos
>>  which contain broken artifacts. This repo historically had a _very_ bad
>>  quality, serving broken artifacts, wrong md5 sums, etc. Most of those
>>  artifacts also have been available on maven.central - but with a checked 
> and
>>  confirmed quality! So back in the days if one project enabled the 
> java.netrepo and you downloaded such artifacts from there, then you were 
> basically
>>  doomed for the rest of your ~/.m2/repository life ;)
>> 
>

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

Re: Maven 3, _maven.repositories and *lastUpdated

[Mark Struberg]

Before we go ahead and drop this feature again, I just like to make sure that 
all people understand _why_ this got implemented the way it is!

If you have lots of projects locally and some projects need an additional 
repository x, then you just add this repo-x to the  section of 
your projects pom. While building your project some artifacts will get 
downloaded. 


Let's say you have the repository.jboss.org added to your project and did 
download JBoss Arquillian. After a build, the arquillian artifacts will then be 
available in your local repository.

Let's assume you then start another project but you don't add the 
repository.jboss.org. The old maven behaviour was that you still have access to 
all artifacts in your local repo. So your project will build just fine locally, 
but if you push your project to github and another person tries to build this 
project he would get an error because he cannot resolve the arquillian 
artifacts!

Another problem did arise with the java.net maven repo and other repos which 
contain broken artifacts. This repo historically had a _very_ bad quality, 
serving broken artifacts, wrong md5 sums, etc. Most of those artifacts also 
have been available on maven.central - but with a checked and confirmed 
quality! So back in the days if one project enabled the java.net repo and you 
downloaded such artifacts from there, then you were basically doomed for the 
rest of your ~/.m2/repository life ;) 

Because even other projects which didn't have the java.net repo enabled would 
now fail.

Benjamin, did I forget any other important point?

I think if we disable the repo separation now, we should aim to not default 
back to our original behaviour which also caused lots of problems.

LieGrue,
strub





- Original Message -
> From: Mark Derricutt 
> To: Maven Users List 
> Cc: 
> Sent: Sunday, October 23, 2011 7:17 PM
> Subject: Re: Maven 3, _maven.repositories and *lastUpdated
> 
> Hrm  - this should exactly like the behavior that the newer Aether library
> -already- solves, as has done for months when you drop in the newer version.
> 
> I know this post is more about disabling the feature, but ignoring it makes
> WAY more sense IMHO.  If, as you say - "Artifact A downloaded from X is not
> the same thing to Maven 3 as A downloaded from Y" then the entire GAV is a
> lie as it DOESN'T actually identify an artifact.
> 
> Mark
> Still wanting that 3.0.4 release...
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven 
> Wilson,
> Porcupine Tree
> 
> 
> On Sun, Oct 23, 2011 at 6:19 AM, Jason van Zyl  wrote:
> 
>>  The artifacts have an identity. It matters where the artifacts were
>>  downloaded from. Artifact A downloaded from X is not the same thing to 
> Maven
>>  3 as A downloaded from Y. This can happen when you flip your settings.xml 
> to
>>  go from using a repository manager to using Maven Central directly for
>>  example.
>> 
>>  There is currently no way to turn that off. But you can vote for the
>>  issue[1].
>> 
>>  [1]: http://jira.codehaus.org/browse/MNG-5181
>> 
>>  On Oct 22, 2011, at 10:05 AM, Stefan Eder wrote:
>> 
>>  > With Maven 3 dependency resolution may fail for artifacts, which have
>>  once been fetched from a remote repository, even so they are available
>>  within the local repository.
>>  > Guess there is a good reason for that and I would like to understand 
> it
>>  and I would like to know if there is a way to switch this behaviour off.
>>  >
>>  > Thanks, Stefan
>>  >
>>  >
>>  > -
>>  > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>  > For additional commands, e-mail: users-h...@maven.apache.org
>>  >
>> 
>>  Thanks,
>> 
>>  Jason
>> 
>>  --
>>  Jason van Zyl
>>  Founder,  Apache Maven
>>  http://twitter.com/jvanzyl
>>  -
>> 
>>  In short, man creates for himself a new religion of a rational
>>  and technical order to justify his work and to be justified in it.
>> 
>>   -- Jacques Ellul, The Technological Society
>> 
>> 
>> 
>> 
>> 
>

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

Re: writing a parent pom that does not execute its plugins

[Mark Struberg]

Some plugins already provide the following 2 properties

* skip
* forceMojoExecution

The idea is that those plugins must not get executed when the project is of 
type 'pom'. But since most of this plugins in bigger projects get defined in a 
'backend-parent' module (or kind of) which is the parent of all backend 
modules, it's pretty hard otherwise.

Example being the sql-maven-plugin [1], the openjpa-maven-plugin, etc


We have been discussing about generalizing this approach, but we would need a 
bit brainstorming still as there are mojos which explicitely gets executed on 
the parent pom (also).

Generalized I'd say there are 3 types of plugins:

a.) sql-maven-plugin like only need to get executed in projects with packaging 
!= pom
b.) aggregator mojos (like javadoc-aggregated) which run _only_ on the parent 
pom
c.) mojos which need to get executed in every project (like the site-plugin)

LieGrue,
strub


[1] http://mojo.codehaus.org/sql-maven-plugin/execute-mojo.html


- Original Message -
> From: Dirk Olmes 
> To: Maven Users List 
> Cc: 
> Sent: Wednesday, October 19, 2011 7:55 PM
> Subject: Re: writing a parent pom that does not execute its plugins
> 
> Am 18.10.2011 um 14:41 schrieb Anders Hammar :
> 
>>  Today, activating a profile defined in a parent from the child is not 
> possible.
> 
> I was able to make the profile idea work in the end. The trick is the 
> enablement: the parent module defines a profile that is enabled through a 
> property. The child module defines that property. Works like a charm.
> 
> More details here: 
> http://xanthippe.dyndns.org/blog/index.php?/archives/33-Templating-Maven-plugin-configurations.html
> 
> -dirk
> -
> 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: maven failing to resolve artifact that exists in repository

[Mark Struberg]

Hi!

it seems that this repository is not listed in the projects pom. So it seems to 
be assumed that you add the following analog for what I did for the jboss repos 
to your ~/.m2/settings.xml:


  
  jbossrepo
  
  
  jboss-public-repository-group
  JBoss Public Repository Group
  
http://repository.jboss.org/nexus/content/groups/public/
  default
  
  true
  never
  
  
  true
  never
  
  
  
  
  
  jboss-public-repository-group
  JBoss Public Repository Group
  
http://repository.jboss.org/nexus/content/groups/public/
  
  true
  
  
  true
  
  
  
  
  

just change the profilename to 'glassfishrepo' and use the URL as you need it.

Then start maven with this profile activated:

>$ mvn clean install -Pglassfishrepo

LieGrue,
strub

- Original Message -

> From: Mike Power 
> To: Maven Users List 
> Cc: 
> Sent: Saturday, October 15, 2011 7:00 AM
> Subject: maven failing to resolve artifact that exists in repository
> 
> I am really confused.  Maven is failing to resolve an artifact that I can 
> easily 
> find in the remote repository.
> 
> I am trying to build an open source project whose git repository is found at
> 
> https://github.com/magnayn/Jenkins-Repository.git
> 
> I get the following error:
> Downloading: 
> http://download.java.net/maven/2//org/kohsuke/stapler/stapler/1.167/stapler-1.167.jar
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
> 
> Missing:
> --
> 1) org.kohsuke.stapler:stapler:jar:1.167
> 
>   Try downloading the file manually from the project website.
> 
>   Then, install it using the command:
>       mvn install:install-file -DgroupId=org.kohsuke.stapler 
> -DartifactId=stapler -Dversion=1.167 -Dpackaging=jar -Dfile=/path/to/file
> 
>   Alternatively, if you host your own repository you can deploy the file 
> there:
>       mvn deploy:deploy-file -DgroupId=org.kohsuke.stapler 
> -DartifactId=stapler 
> -Dversion=1.167 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
> -DrepositoryId=[id]
> 
>   Path to dependency:
>       1) com.nirima.jenkins.repository:pom:pom:0.6.2-SNAPSHOT
>       2) org.jenkins-ci.main:jenkins-core:jar:1.417
>       3) org.kohsuke.stapler:stapler-adjunct-timeline:jar:1.3
>       4) org.kohsuke.stapler:stapler:jar:1.167
> 
> --
> 1 required artifact is missing.
> 
> for artifact:
>   com.nirima.jenkins.repository:pom:pom:0.6.2-SNAPSHOT
> 
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   m.g.o-public (http://maven.glassfish.org/content/groups/public/)
> *
> *
> 
> It seems to be only trying central.  However it is not available on central.  
> It 
> is available on m.g.o-public.  Here is the url: 
> http://maven.glassfish.org/content/groups/public/org/kohsuke/stapler/stapler/1.161/stapler-1.161.jar
> 
> Why is maven going to central to find the jar, and not going to 
> m.g.o-public?  
> It says it tried m.g.o-public but I do not see that happening.*
> *
>

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

RE: Parallel download dependencies in same group

[Mark Struberg]

Hi!

Of course, any help is welcome. But mind the problems which may arise:
You can only download in parallel after all poms got fully parsed 

Imo all the archive resolver stuff must first downloading all the poms and 
parse them. This must not be done in parallel because you don't know yet if 
there are things which could be done in parallel.
But of course, downloading the jars and other types might well be done with 
parallel requests.

LieGrue,
strub
 

--- On Fri, 8/12/11, Gaurav Arora  wrote:

> From: Gaurav Arora 
> Subject: RE: Parallel download dependencies in same group
> To: "Maven Users List" 
> Date: Friday, August 12, 2011, 7:01 AM
> I have noticed that if I download two
> separate builds from Nexus, they
> both download at the same speed. It's almost as if parallel
> downloads
> (upto a certain point) are faster on nexus hence the
> request.
> 
> Would it be okay if I worked on this and submitted a patch
> to download
> dependencies in parallel? I'm not sure how patch
> submissions work in the
> maven ecosystem so any links would be most helpful.
> 
> Thanks,
> Gaurav
> 
> -Original Message-
> From: Wayne Fay [mailto:wayne...@gmail.com]
> Sent: Thursday, August 11, 2011 9:08 PM
> To: Maven Users List
> Subject: Re: Parallel download dependencies in same group
> 
> > That was my initial idea too. But the problem is that
> these are trunk
> builds
> > with deep dependencies so they change very frequently.
> Most likely if I
> > rerun my tests 30 minutes later then I will recieve a
> new build because
> one
> > of the many in-house libraries has changed. We also
> work within a large
> team
> > where developers are frequently changing code so the
> version keeps
> updating.
> 
> Eventually you're going to have to pay the price for
> having
> development and builds happen in one area of the world and
> testing
> happen in another with a too-small Internet pipe connecting
> them.
> 
> Sounds like you need a local CI server + local Nexus slave
> + "mvn
> verify" job that runs every 10 or 15 minutes. The downloads
> will
> merely consume CPU time on your CI server rather than
> wasting your
> time.
> 
> Wayne
> 
> -
> 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
> 
> 

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

Re: Need help

[Mark Struberg]

hi Adrien!

You could try the maven-depedency-plugin dependency:unpack goal [1].

LieGrue,
strub

[1] http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html

--- On Tue, 8/9/11, Adrien Ruffie - Petals Link  
wrote:

> From: Adrien Ruffie - Petals Link 
> Subject: Need help
> To: users@maven.apache.org
> Date: Tuesday, August 9, 2011, 9:57 AM
> Hello allo,
> I have this following case:
> in my first project "project1" I have a dependency
> "project2".
> 
> In this following "project2" (isn't jar type but .zip
> type), I have
> a project2.wsdl, I wanted to copy in the first project
> "project1"
> at the root jar directory, example:
> 
> project2: ---> /META-INF
>            
>    /Classes
>            
>    /project2.wsdl
> 
> Do you have an idea, how can I make this ?
> 
> Thank you
> 
> Best regards,
> 
> Adrien Ruffié
> 
> -- Adrien Ruffié
> - Ingénieur de recherches et développements
> - Scrum Team member
> 
> 
> 
> -
> 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: How can we avoid "checking for updates" for jars we already have?

[Mark Struberg]

Hi Trent!

Just use the  setting in the  section for the 
specific repository and set it to 'never' or 'daily'.

You can either set this in your own pom.xml or in your ~/.m2/settings.xml [1].

LieGrue,
strub



[1] http://maven.apache.org/ref/2.0.8/maven-settings/settings.html
--- On Fri, 8/5/11, Trent Larson  wrote:

> From: Trent Larson 
> Subject: How can we avoid "checking for updates" for jars we already have?
> To: users@maven.apache.org
> Date: Friday, August 5, 2011, 10:53 PM
> Our Maven builds suddenly started
> failing a few days ago, apparently because
> our chosen mirror (for repo1.maven.org/maven2) is no longer
> accessible.
> 
> Here is the output:
> 
> [INFO] artifact org.springframework:spring-core: checking
> for updates from
> central
> [WARNING] repository metadata for: 'artifact
> org.springframework:spring-core' could not be retrieved
> from repository:
> central due to an error: Error transferring file
> [INFO] Repository 'central' will be blacklisted
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to resolve artifact.
> 
> No versions are present in the repository for the artifact
> with a range
> [2.5.2,3)
>   org.springframework:spring-core:jar:null
> 
> 
> I can think of a few solutions:
> 
> - Let's just avoid downloading jars we already have! 
> We've got the
> following in our .m2/repository:
> org/springframework/spring-core/2.5.5/spring-core-2.5.5.jar
> 
> This seems like the simplest solution... I guess I don't
> understand why
> Maven is checking external repos for something it already
> has.  BTW, we
> don't depend on spring-core directly, so I assume it's due
> to a transitive
> dependency from this:
>    
>      
> org.springframework
>      
> spring
>       2.5.5
>     
> 
> - Maybe there's a metadata setting for those Spring
> artifacts where I can
> force it to stop going external.  (I tried specifying
> spring-core directly
> so it won't look elsewhere, to no avail.)  It looks
> like it's seeking some
> "range" of versions for some reason.  Maybe there's a
> way to specify the
> version of this transitive dependency in some other
> dependency somewhere.
> But I don't see any way to do those things.  (How can
> I see which other
> thing is including this particular spring-core?)
> 
> - If we can get to repo1.maven.org/maven2, that would be
> nice, but we
> cannot.  (At least, it doesn't come up in my
> browser.)  And we used to use a
> mirror, but now we can't get to any of the known mirrors,
> either.  Someone
> just mentioned that there have been issues due to the
> recent IP
> changes,
> and that seems to say that repo1 is still available... but
> shouldn't it come
> up in my browser?
> 
> Thanks for any ideas.
> Trent
>

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

Re: mvn release is failing with git

[Mark Struberg]

Erwin,

do you have a log of the git push command which fails? We log it to the console 
in case of an error.
Please try to execute this command manually and check if there are any errors 
too.

LieGrue,
strub

--- On Thu, 8/4/11, Stephen Connolly  wrote:

> From: Stephen Connolly 
> Subject: Re: mvn release is failing with git
> To: "Maven Users List" 
> Date: Thursday, August 4, 2011, 6:43 AM
> release activates some profiles which
> will result in the active by default
> profiles no longer being so
> 
> - Stephen
> 
> ---
> Sent from my Android phone, so random spelling mistakes,
> random nonsense
> words and other nonsense are a direct result of using swype
> to type on the
> screen
> On 4 Aug 2011 03:10, 
> wrote:
> > Hallo,
> >
> > I have an error in maven release plugin (mvn
> release:prepare):
> >
> > [ERROR] The git-push command failed.
> > [ERROR] Command output:
> > [ERROR] fatal: The remote end hung up unexpectedly
> >
> > But I'm sure that the remote repository works just
> fine. Is there
> difficulties with the git protocol? I post my settings.xml
> and pom.xml:
> >
> > @- settings.xml
> > 
> >
> > 
> > 
> > Repository Root Locations Local
> > 
> > true
> > 
> > 
> > http://localhost:8080/archiva
> 
> >
> git://localhost/~devent
> > 
> > 
> > ...
> > -@
> >
> > @- pom.xml
> > 
> >
> scm:git:${git.repository.root}/xmlstorage.git
> 
> >
> scm:git:${git.repository.root}/xmlstorage.git
> 
> >
> scm:git:scm:git:${git.repository.root}/xmlstorage.git
> 
> > 
> >
> > 
> > 
> > globalscaling.com-public
> >
> ${archiva.repository.root}/repository/globalscaling.com-public/
> > 
> > 
> >
> globalscaling.com-public-snapshots
> >
> ${archiva.repository.root}/repository/globalscaling.com-public-snapshots/
> > 
> > 
> > -@
> >
> > I have them in properties because I like to change
> them without to touch
> the pom.xml. Sometimes I work at home, there I have a good
> internet
> connection, but sometimes I work with my laptop with no/bad
> connection. So I
> setup a git repository and Archiva on localhost.
> >
> > git pull and git push works, and mvn deploy works,
> too. mvn scm update
> works, too. So I don't understand, if I use the ssh
> protocol in the URLs,
> mvn release works just fine. Is it an issue with the git
> protocol?
> >
> > Kind regards, Erwin.
> >
> > --
> > Erwin Mueller, erwin.muel...@deventm.org
> > http://www.global-scaling-institute.de/
> > http://www.deventm.org
> >
> >
> -
> > 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: Getting strange error in compilation

[Mark Struberg]

If I remember correctly, then this is also needed for native2ascii resource 
conversion. Anyone checking this?

LieGrue,
strub

--- On Sun, 7/31/11, Kathryn Huxtable  wrote:

> From: Kathryn Huxtable 
> Subject: Re: Getting strange error in compilation
> To: "Maven Users List" 
> Date: Sunday, July 31, 2011, 11:41 PM
> I've been working on a Swing
> pluggable look & feel, and was needing to include
> rt.jar. I have a separate profile for the Mac. The relevant
> sections of my pom look like:
> 
> ...
> 
>     
>         
>            
> org.apache.maven.plugins
>            
> maven-compiler-plugin
>            
> 2.3.2
>            
> 
>            
>     1.6
>            
>     1.6
>            
>     
>            
>        
> ${java.home}/lib/rt.jar
>            
>     
>            
> 
>         
>     
> ...
> 
>     
>        
> mac
>         
>            
> 
>            
>     mac
>            
> 
>         
>         
>            
> 
>            
>     
>            
>     
>            
>        
> org.apache.maven.plugins
>            
>        
> maven-compiler-plugin
>            
>        
> 2.3.2
>            
>         
>            
>            
> 1.6
>            
>            
> 1.6
>            
>            
> 
>            
>            
>    
> ${java.home}/bundle/Classes/classes.jar
>            
>            
> 
>            
>        
> 
>            
>     
>            
> 
>         
>     
> ...
> 
> I think most artifacts don't need to include rt.jar, so I
> don't know what you'd do. I suppose we can add the JDK
> version to the activation profile...
> 
> I don't think you folks need to do anything, but I was
> bewildered, and Google wasn't much help, though I did
> eventually find a solution through a Google search, just not
> the first several I tried.
> 
> -K
> 
> On Jul 31, 2011, at 6:27 PM, Barrie Treloar wrote:
> 
> > On Mon, Aug 1, 2011 at 8:23 AM, Kathryn Huxtable
> > 
> wrote:
> >> Okay, I see. Apple changed the location of
> classes.jar, which is what they call rt.jar in a recent
> release of Java, possibly update 26.
> > 
> > How did you fix this then?
> > 
> > Do we need to configure maven to understand this
> natively?
> > 
> >
> -
> > 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
> 
>

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

Re: gitflow releases with maven?

[Mark Struberg]

Hi Lars!

Oki, I understand. Will try to look at it the next week.

LieGrue,
strub

--- On Fri, 7/29/11, Lars Fischer  wrote:

> From: Lars Fischer 
> Subject: Re: gitflow releases with maven?
> To: "Maven Users List" 
> Date: Friday, July 29, 2011, 8:34 AM
> Hello Mark,
> 
> I see, that you assigned MRELEASE-624. Thank you for the
> quick reaction!
> 
> 
> 2011/7/29 Mark Struberg :
> >
> > Do you have  activated?
> > You might try disabling it, maybe there is a bug with
> that on windows.
> >  is meant to spare bandwith in
> huge projects by doing a git-clone file:// from the local
> git repo instead of cloning the upstream repo in
> release:perform.
> 
> Yes, localCheckout=true and pushChanges=false are used,
> because the
> maven-release-plugin should perform only local changes.
> Gitflow has to do additional branching / merging, which has
> to be
> pushed outside the maven-release-plugin.
> 
> Regards,
> Lars
> 
> -
> 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: gitflow releases with maven?

[Mark Struberg]

hi!

Do you have  activated?
You might try disabling it, maybe there is a bug with that on windows.
 is meant to spare bandwith in huge projects by doing a 
git-clone file:// from the local git repo instead of cloning the upstream repo 
in release:perform.

LieGrue,
strub

--- On Fri, 7/29/11, Lars Fischer  wrote:

> From: Lars Fischer 
> Subject: Re: gitflow releases with maven?
> To: "Maven Users List" 
> Date: Friday, July 29, 2011, 8:03 AM
> 2011/7/29 Mark Derricutt :
> >
> > Hrm - I still believe that master would be
> "production-ready-state" even with the -SNAPSHOT version,
> > the code is in a state that ready for production
> release.  If I did a maven release from there I'd get
> > the same code built, with the only difference being
> the version number.  If I checked out master and
> > did a maven install, I'd expect to get a SNAPSHOT and
> not something that's going to overwrite existing
> > released artifacts.
> >
> >> It must not match the maven repo, but there should
> not be a SNAPSHOT-pom on HEAD
> >
> > As above I beg to differ.
> 
> Hmm, this is what I understand from the gitflow
> documentation and what
> results, when performing a manual release without the
> maven-release-plugin.
> 
> But you are right, ignoring this restriction is no real
> problem.
> 
> 
> >> [...]
> >> [INFO] --- maven-release-plugin:2.2:perform
> (default-cli) @ master ---
> >> [INFO] Checking out the project to perform the
> release ...
> >> [INFO] Performing a LOCAL checkout from
> >>
> scm:git:file://D:\dev\projects\maven.master\source\maven.master
> >> [INFO] Executing: cmd.exe /X /C "git clone
> >>
> file://D\dev\projects\maven.master\source\maven.master
> >>
> D:\dev\projects\maven.master\source\maven.master\target\checkout"
> >
> > Interesting - I see you have maven.master mentioned
> twice in the path -
> > what do you have in your SCM settings element?
> 
> 
>  
> scm:git:ssh://git@myserver:22/maven.master.git
>  
> scm:git:ssh://git@myserver:22/maven.master.git
> 
> 
> 
> >  And what is the root path of the git repo
> 
> The file path to the local clone is:
> D:\dev\projects\maven.master\source\maven.master
> 
> There are two "maven.master", because I organize my
> projects in
> subfolders with eclipse workspace folders parallel to the
> source
> folders (e.g. D:\dev\projects\maven.master\workspace).
> 
> 
> > and are you releasing from that directory?
> 
> Both, the git and mvn commands are executed from
> "D:\dev\projects\maven.master\source\maven.master"
> 
> 
> 
> 
> Could this be a Windows problem?
> 
> I tried to perfom a second clone from the local file path
> with the
> generated maven path:
> "git clone
> file://D:\dev\projects\maven.master\source\maven.master"
> 
> This results in:
> 
> Cloning into devprojectsmaven.mastersourcemaven.master...
> fatal: 'd:devprojectsmaven.mastersourcemaven.master' does
> not appear to be a git
>  repository
> fatal: The remote end hung up unexpectedly
> 
> 
> When using a different path with slashes
> "git clone
> file:///d:/dev/projects/maven.master/source/maven.master/"
> everything works fine.
> 
> 
> Regards,
> Lars
> 
> -
> 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: Plugin development using Guice?

[Mark Struberg]

It is currently possible but it's not guaranteed to run forever. If there is no 
unique feature which you can only do with guice, then I'd still suggest doing 
it the 'old' way. 

There have been discussions about switching from JSR-330 to the more powerful 
JSR-299 spec for DI. So if you like to keep it save, then just use plexus. Also 
keep in mind that there are other libraries already which emulate the plexus 
container not via guice but via Spring. This actually pre-dates the guice work 
by far and is still in use...

LieGrue,
strub 

--- On Fri, 7/8/11, Johannes Schneider  wrote:

> From: Johannes Schneider 
> Subject: Plugin development using Guice?
> To: "Maven Users List" 
> Date: Friday, July 8, 2011, 8:36 AM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi guys,
> 
> 
> is it possible to use Guice for new plugins? Since Maven is
> build on top
> of Guice, this should be possible, does it?
> 
> A link to an existing plugin using Guice would be great, if
> there
> existed one.
> 
> 
> Thanks,
> 
> Johannes
> 
> - -- 
> Johannes Schneider - blog.cedarsoft.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJOFsGaAAoJEAytD9R7Qv6dduYIAMb515pWUZvTFJnkJGL9dvl6
> yVZgn3p3KnAGfgrjynH121VO+DrNn0IEmipbs+95QPF4Sn6gN3DNUiQH2244CeoZ
> ir7BN2z84aW6j/G+WqEo8JFI4qurF2P/n6+2nrpdBjmOUg5zQzly975TCmpnuOnh
> 7HbEzhFymtzKfyiql2wV6qCiWHSRq5Q/IzZDNQkM76oe6HYBlYGV//Rv3uxIcJqa
> 6G2zWTtGOd4csMAXpkPjK5BmQc7+Yf/+wsPSINF2mThJmtUx17bVwLogmLA/YHEd
> mYiB4xKUHIi2goXglJviT5dpd1qUbKCP228rargv44OUNFWgmNjcgIAw+VhYfDg=
> =+jgF
> -END PGP SIGNATURE-
> 
> -
> 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

Welcome Robert Scholte to the Apache Maven team!

[Mark Struberg]

Hi Maven folks!

The Apache Maven PMC is glad to welcome Robert Scholte as new Apache Maven 
Committer!
Most of us know Robert already from his dedicated work on lots of Maven plugins 
over at codehaus-mojo, so I guess I don't have to add much ;)

Robert, congratulations and happy hacking!

LieGrue,
strub

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

Re: question about mvn dir structure

[Mark Struberg]

$> mvn archetype:generate 

There are some 100 archetypes for various project types available. Please pay 
attention that the first 'simple' app (no 3 or so) is _not_ the simplest app 
available - it's just badly named.

LieGrue,
strub


--- On Thu, 6/30/11, Joseph  wrote:

> From: Joseph 
> Subject: Re: question about mvn dir structure
> To: "Maven Users List" 
> Date: Thursday, June 30, 2011, 5:37 AM
> app was created by command line.
> 
> "Yes, you'd need to match the package structure for
> resources ..." <--
> all by hand coding ? any tools or tricks that do?
> 
> 2011/6/30 Wendy Smoak :
> > On Wed, Jun 29, 2011 at 9:12 PM, Joseph 
> wrote:
> >> I am a newbie for mvn and have a simple question
> about dir structure.I
> >> know the basic dirs were created automaticlly by
> mvn after
> >> initialization setup of a web apps.Then what I do
> is just code and
> >> create some packages under src/main/java,but the
> resource and test
> >> directories did not updated .Do I have to create
> dir(package) under
> >> resource/test manually to align against
> src/main/java structure? or do
> >> we have some tricks that could accomplish that?
> >
> > How did you set up your webapp?  Did you use the
> archetype plugin at
> > the command line, or are you using an IDE?
> >
> > (Yes, you'd need to match the package structure for
> resources and
> > tests so things end up where they belong.)
> >
> > --
> > Wendy
> >
> >
> -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> 
> 
> 
> -- 
> Never trust your computer.
> 
> -
> 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: Hit java.lang.IllegalStateException with Wagon-ssh

[Mark Struberg]

Hi!

maven-2.2.1 is fine. 

Maybe you had a download problem? Try to 
rm -rf /Users/sshark/.m2/repository/org/apache/maven/wagon

and start your build again.

LieGrue,
strub

--- On Sun, 6/26/11, thlim  wrote:

> From: thlim 
> Subject: Hit java.lang.IllegalStateException with Wagon-ssh
> To: users@maven.apache.org
> Date: Sunday, June 26, 2011, 4:13 PM
> Hi, 
> 
> I want to use wagon-ssh (1.0-beta-7) plugin to deploy my
> assembled (via
> assembly:assembly) application to another server using SSH.
> It failed with a
> fatal error, 
> 
> [INFO]
> 
> 
> [ERROR] FATAL ERROR 
> [INFO]
> 
> 
> [INFO] The plugin descriptor for the plugin Plugin
> [org.apache.maven.wagon:wagon-ssh] was not found. Please
> verify that the
> plugin JAR
> /Users/sshark/.m2/repository/org/apache/maven/wagon/wagon-ssh/1.0-beta-7/wagon-ssh-1.0-beta-7.jar
> is intact. 
> [INFO]
> 
> 
> [INFO] Trace 
> java.lang.IllegalStateException: The plugin descriptor for
> the plugin Plugin
> [org.apache.maven.wagon:wagon-ssh] was not found. Please
> verify that the
> plugin JAR
> /Users/sshark/.m2/repository/org/apache/maven/wagon/wagon-ssh/1.0-beta-7/wagon-ssh-1.0-beta-7.jar
> is intact. 
> 
> My maven and OS versions are stated below. Can anyone help
> me as of why the
> wagon plug in is not intact? Does it require maven 3?
> Thanks 
> 
> Apache Maven 2.2.1 (r801777; 2009-08-07 03:16:01+0800) 
> Java version: 1.6.0_24 
> Java home:
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> 
> Default locale: en_US, platform encoding: MacRoman 
> OS name: "mac os x" version: "10.6.8" arch: "x86_64"
> Family: "mac" 
> 
> 
> /lim/

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

RE: generated artifact name

[Mark Struberg]

Hi!

This happens if you set a  in your build section.

This is handy if you have some automated task which assumes that there exists a 
file this certain name.


LieGrue,
strub

--- On Thu, 6/23/11, Yuvaraj Vanarase  wrote:

> From: Yuvaraj Vanarase 
> Subject: RE: generated artifact name
> To: "Maven Users List" 
> Date: Thursday, June 23, 2011, 3:08 PM
> Anyone has any clue?
> 
> Regards,
> Yuvaraj
> 
> Yuvaraj Vanarase,
> Lead Technology - Software
> Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870
> | http://www.synechron.com
> SYNECHRON - 
> - Top 10 Best IT Employers for 4 consecutive years (link).
> - Celebrating 10 Years!
> 
> 
> -Original Message-
> From: Yuvaraj Vanarase [mailto:yuvaraj.vanar...@synechron.com]
> 
> Sent: Thursday, June 23, 2011 3:00 PM
> To: users@maven.apache.org
> Subject: generated artifact name
> 
> Hi,
> 
> Sometimes I observed that jar/ear artifact created under
> target directory after maven install/package goal doesn't
> have version in its name. Well, while installing it does
> install to correct directory structure under local
> repository.
> 
> E.g.
> 
> abc
>            
> com.xyz
>            
> 1.0.0
> 
> Creates abc.ear instead of abc-1.0.0.ear (or jar if jar is
> the packaging).
> 
> Regards,
> Yuvaraj
> 
> Yuvaraj Vanarase,
> Lead Technology - Software
> Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | 
> http://www.synechron.com
> SYNECHRON -
> - Top 10 Best IT Employers for 4 consecutive years
> (link).
> - Celebrating 10 Years!
> 
> 
> -
> 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: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Mark Struberg]

humm, maybe the resolution mechanism sniffs _all_ snapshot timeshot versions 
and not only the last one?

Could you please re-add the snapshot repo and set the version ranges to 
[8.0.0,9.0.0)?

The question is if this is related to the fact that the snapshot repo just has 
lots of artifacts (due to the timestamping) or if it's related to the -SNAPSHOT 
in the version range.

txs and LieGrue,
strub

--- On Wed, 6/22/11, Paul French  wrote:

> From: Paul French 
> Subject: Re: maven 3.0.3 out of memory error, version ranges, lots of maven 
> meta downloads
> To: users@maven.apache.org
> Cc: "Ian Jones" 
> Date: Wednesday, June 22, 2011, 8:26 AM
> Thanks for that.
> 
> Out of interest if I remove the snapshot repository and
> change my version ranges to [8.0.0,9.0.0) instead of
> [8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in
> eclipse.
> 
> For now we will live without snapshots.
> 
> 
> On 22/06/2011 06:21, Kristian Rosenvold wrote:
> > From what I can understand this issue is almost
> certainly some kind of combinatorial explosion caused in the
> calculation of the dependencies. Sample project/and or heap
> dumps will be required here as far as I can understand.
> > 
> > As for the embedded building, you might want to take
> note that plexus-utils 2.1 fixes a memory leak wrt
> embedding.  This has been released in surefire 2.9.
> maven-scm and the xAR plugins also have the same problem and
> can be fixed by upgrading the plexus-utils dependency to 2.1
> in these plugins.
> > 
> > Kristian
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> -
> > 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
> 
>

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

Re: How to bind ant to a maven-plugin custom goal

[Mark Struberg]

There is an example of such a plugin in 'Maven - The Definitive Guide" 
available somewhere as free PDF I'm sure.

LieGrue,
strub

--- On Fri, 6/17/11, Stephen Connolly  wrote:

> From: Stephen Connolly 
> Subject: Re: How to bind ant to a maven-plugin custom goal
> To: "Maven Users List" 
> Date: Friday, June 17, 2011, 11:22 AM
> create a maven plugin using the ANT
> bindings
> 
> http://maven.apache.org/plugin-tools/maven-plugin-tools-ant/index.html
> 
> I can't find the example for an ANT based plugin at the
> moment... should be
> more promenant though
> 
> On 17 June 2011 12:10, Markos Charatzas 
> wrote:
> 
> > The way to integrate maven with ant is to simply use
> the
> > maven-antrun-plugin
> > like
> >
> >
> > 
> >   
> org.apache.maven.plugins
> >   
> maven-antrun-plugin
> >    1.6
> >    
> >        
> >           
> package
> >           
> package
> >           
> 
> >               
> 
> >         target="package" />
> >      
> >    
> >           
> 
> >               
> run
> >           
> 
> >        
> >    
> > 
> >
> >
> > in your project's pom.xml file
> >
> > However I want to be able to have that associated
> build.xml script along
> > with the execution configuration as part of a maven
> plugin that defines a
> > custom packaging and a lifecycle.
> >
> > Is there a way to do that?
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/How-to-bind-ant-to-a-maven-plugin-custom-goal-tp4498426p4498426.html
> > Sent from the Maven - Users mailing list archive at
> Nabble.com.
> >
> >
> -
> > 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: An example of a plugin that uses the as an actual live classpath ...

[Mark Struberg]

I think the question is ambiguous:

Did he like to get the classpath of all dependencies of the current project to 
invoke a java method which needs those classes on the classpath (annotation 
scanning or enhancement, etc)? 

Or does he like to contruct a classpath string which he can pass to a shell 
invocation?

LieGrue,
strub

--- On Fri, 6/17/11, Jörg Schaible  wrote:

> From: Jörg Schaible 
> Subject: Re: An example of a plugin that uses the  as an 
> actual live classpath ...
> To: users@maven.apache.org
> Date: Friday, June 17, 2011, 7:27 AM
> Benson Margulies wrote:
> 
> > I find myself looking to create a plugin where, as
> part of execution,
> > it wants to create a classpath composed of the
> declared dependencies.
> > Can anyone suggest a model?
> 
> Not sure, which plugin I used to look this up, but I had
> once the need to 
> scan the compiled classes for annotations and to load them;
> I had to build 
> my own classloader:
> 
>  %< =
> private ClassLoader getCompilationClassLoader() throws 
> DependencyResolutionRequiredException
> {
>   final Log log = getLog();
>   @SuppressWarnings("unchecked")
>   final List classpathElements = 
> project.getCompileClasspathElements();
> 
>   final List urls = new
> ArrayList();
>   for (final String classpathElement :
> classpathElements) {
>     try {
>       final URL url = new
> File(classpathElement).toURI().toURL();
>       if (log.isDebugEnabled()) {
>         log.debug("Add to compilation
> classpath: " + url.toString());
>       }
>       urls.add(url);
>     } catch (final MalformedURLException e) {
>       log.warn("Cannot convert strange class
> path element into URL: " + 
> classpathElement);
>     }
>   }
> 
>   return new URLClassLoader(urls.toArray(new
> URL[urls.size()]), 
> Thread.currentThread().getContextClassLoader());
> }
>  %< =
> 
> - Jörg
> 
> 
> -
> 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: An example of a plugin that uses the as an actual live classpath ...

[Mark Struberg]

You might look at the way we did it for the openjpa-maven-plugin:

https://svn.codehaus.org/mojo/trunk/mojo/openjpa-maven-plugin/src/main/java/org/codehaus/mojo/openjpa/AbstractOpenJpaMojo.java

check the extendRealmClasspath() method.

LieGrue,
strub

--- On Wed, 6/15/11, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: An example of a plugin that uses the  as an actual 
> live classpath ...
> To: "Maven Users List" 
> Date: Wednesday, June 15, 2011, 3:09 PM
> I find myself looking to create a
> plugin where, as part of execution,
> it wants to create a classpath composed of the declared
> dependencies.
> Can anyone suggest a model?
> 
> -
> 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: Missing artifact javax.transaction:jta:jar:1.0.1B

[Mark Struberg]

right.

A slightly OT addendum: All projects which need IP clean ALv2 licensed 
dependencies might have a look at the Geronimos specs project [1] which 
contains artifacts of lots of JSRs.

Especially all apache.org projects should use those dependencies instead of 
their (mostly) CDDL licensed counterparts from over at java.net!

LieGrue,
strub

[1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/

--- On Wed, 6/15/11, Marc Rohlfs  wrote:

> From: Marc Rohlfs 
> Subject: Re: Missing artifact javax.transaction:jta:jar:1.0.1B
> To: "Maven Users List" 
> Date: Wednesday, June 15, 2011, 7:37 AM
> Hi,
> 
> the artifact does not exists in Central, right. But there's
> no need to download and install it manually. The artifact is
> available in the repository http://download.java.net/maven/2, You just only 
> need to
> add it to Your Nexus and/or Maven settings.
> 
> Regards, Marc
> 
> -
> 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: Maven repository on SourceForge file system

[Mark Struberg]

hi!

A slightly different approach would be to use wagon-svn and 'deploy' your 
artifacts to a folder in your apps Subversion repo.
This is a neat hack for getting sharing a maven repo via sourceforge.

LieGrue,
strub 

--- On Sat, 6/11/11, mebigfatguy  wrote:

> From: mebigfatguy 
> Subject: Re: Maven repository on SourceForge file system
> To: users@maven.apache.org
> Date: Saturday, June 11, 2011, 7:29 PM
> 
> > I see the ' which implies to me that the
> sf file system is getting
> > in
> > the way of how maven works. Has anyone tried to do
> this, or am I out of
> > luck.
> > 
> > Perhaps try linking directly to the file via the CDN:
> > http://cdnetworks-us-2.dl.sourceforge.net/project/fb-contrib/repo/com/mebigfatguy/fb-contrib/4.6.1/fb-contrib-4.6.1.pom
> > 
> > Wayne
> 
> 
> Sweet!! that worked, thanks!
> 
> 
> 
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Maven-repository-on-SourceForge-file-system-tp4479412p4479472.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> -
> 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: Can't deploy Maven jar (MDB) on Jboss 6

[Mark Struberg]

hi!

The message you see has nothing to do with maven but with the JBoss deployer. 
I'd check if the mentioned class is available somewhere in your JBoss 
installation. 

In any case 'org.jboss.ejb3.timerservice.spi.TimerServiceFactory' sounds like 
an internal JBoss class. Maybe there is an OSGi problem?

Reporting this on the JBoss forum/Jira seems the way to go.

LieGrue,
strub

--- On Sat, 6/11/11, Jamshed Katta  wrote:

> From: Jamshed Katta 
> Subject: Can't deploy Maven jar (MDB) on Jboss 6
> To: users@maven.apache.org
> Date: Saturday, June 11, 2011, 7:36 AM
> 
> I am using jboss6, message driven bean, hibernate and
> maven2 in my
> application when i try to compile my mdb using maven2 and
> deploy on jboss6 i
> get the following error:
> 
> Failed to create Resource MessageBean.jar - cause:
> java.lang.Exception:Failed to start deployment
> [vfs:///opt/jboss6/server/default/deploy/MessageBean.jar]
> during deployment
> of 'MessageBean.jar' - cause:
> java.lang.RuntimeException:org.jboss.deployers.client.spi.IncompleteDeploymentException:
> Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR
> DETAILS):
> DEPLOYMENTS MISSING DEPENDENCIES: Deployment
> "jboss.j2ee:jar=MessageBean.jar,name=MessageBean,service=EJB3"
> is missing
> the following dependencies: Dependency "interface
> org.jboss.ejb3.timerservice.spi.TimerServiceFactory"
> (should be in state
> "Installed", but is actually in state "Instantiated")
> DEPLOYMENTS IN ERROR:
> Deployment "interface
> org.jboss.ejb3.timerservice.spi.TimerServiceFactory"
> is in error due to the following reason(s): Instantiated
> ->
> org.jboss.deployers.client.spi.IncompleteDeploymentException:Summary
> of
> incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
> DEPLOYMENTS
> MISSING DEPENDENCIES: Deployment
> "jboss.j2ee:jar=MessageBean.jar,name=MessageBean,service=EJB3"
> is missing
> the following dependencies: Dependency "interface
> org.jboss.ejb3.timerservice.spi.TimerServiceFactory"
> (should be in state
> "Installed", but is actually in state "Instantiated")
> DEPLOYMENTS IN ERROR:
> Deployment "interface
> org.jboss.ejb3.timerservice.spi.TimerServiceFactory"
> is in error due to the following reason(s): Instantiated 
> 
> Here is my pom.xml
> 
> 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
>     com.mycompany
>    
> MessageBean
>     ejb
>     1.0-SNAPSHOT
>     MessageBean Java EE 6
> EJB
>     http://maven.apache.org
> 
>     
>         
>            
> log4j
>            
> log4j
>            
> 1.2.12
>         
>          
>            
> org.jboss.ejb3
>            
> jboss-ejb3-timerservice-spi
>            
> 1.0.4
>         
> 
>         
>            
> org.hibernate
>            
> hibernate
>            
> 3.0
>            
> jar
>            
> compile
>         
>         
>            
> org.jboss.ejb3
>            
> jboss-ejb3-ext-api
>            
> 1.0.0
>         
>         
>            
> org.slf4j
>            
> jcl-over-slf4j
>            
> 1.5.6
>            
> test
>         
>         
>            
> org.slf4j
>            
> slf4j-api
>            
> 1.5.6
>            
> test
>         
>         
>            
> javax
>            
> javaee-api
>          
> 6.0
>        
>    jar
>        
>    provided
>             
>         
>        
>            
> javax
>            
> javaee-api
>            
> 6.0
>            
> provided
>         
>         
>            
> junit
>            
> junit
>            
> 3.8.2
>            
> test
>         
> 
>     
> 
>     
>         
>            
> java.net2
>            
> Java.Net Maven2 Repository, hosts the
> javaee-api
> dependency
>             http://download.java.net/maven/2
>         
>         
>            
> jboss-public-repository-group
>             JBoss
> Public Maven Repository Group
>            
> https://repository.jboss.org/nexus/content/groups/public-jboss/
>            
> default
>             
>                
> true
>                
> never
>            
> 
>            
> 
>                
> true
>                
> never
>            
> 
>         
>         
>            
> jboss
>             http://repository.jboss.com/maven2
>             
>                
> true
>            
> 
>            
> 
>                
> false
>            
> 
>         
>         
>            
> jboss-snapshot
>             http://snapshots.jboss.org/maven2
>             
>                
> true
>            
> 
>            
> 
>                
> true
>            
> 
>         
>     
>     
>         
>             
>                
> org.apache.maven.plugins
>                
> maven-compiler-plugin
>                
> 2.0.2
>                
> 
>                
>     1.6
>                
>     1.6
>                
> 
>             
>             
>             

Re: maven3 - how to switch wagon provider (due to long password)

[Mark Struberg]

Hi Miki!

I guess this is because mvn 3 uses wagon-lightweight-http for all read actions.

How do you set your credentials? Via the  tag in settings.xml?
Could you please provide us with an example of such a long password via a Jira 
ticket in 

http://jira.codehaus.org/browse/WAGON

txs and LieGrue,
strub

--- On Fri, 5/27/11, Miki Tebeka  wrote:

> From: Miki Tebeka 
> Subject: maven3 - how to switch wagon provider (due to long password)
> To: users@maven.apache.org
> Date: Friday, May 27, 2011, 12:15 AM
> Greetings,
> 
> I have a long password that causes issues with the default
> wagon
> provider (same as http://jira.codehaus.org/browse/MNG-4754)
> Using maven 2 I was able to solve that by adding
>       
>        
> httpclient
>       
> to ~/.m2/settings.xml
> 
> We switched to maven 3 and the problem reappeared, how can
> I find this
> issue with maven 3?
> 
> All the best,
> --
> Miki
> [I don't suffer from insanity, I enjoy every minute of it]
> 
> -
> 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: Problem in delpoying an external jar to the local repo

[Mark Struberg]

They moved it almost a year ago already 

New one is at 

https://repository.jboss.org/nexus/ 

see 

http://relation.to/Bloggers/JBossMavenRepositoryChanges

LieGrue,
strub


--- On Tue, 5/24/11, Wayne Fay  wrote:

> From: Wayne Fay 
> Subject: Re: Problem in delpoying an external jar to the local repo
> To: "Maven Users List" 
> Date: Tuesday, May 24, 2011, 4:58 PM
> First off, don't EVER post a full
> stack trace like that to this email
> list again unless you have been specifically requested to
> do so. Post
> it somewhere like pastebin.com and send a link here. The
> full stack
> trace is almost never necessary to debug an issue.
> 
> Secondly, can you honestly not grok that stack trace to
> find the root
> cause? Here's a hint, look for the words
> repository.jboss.com in the
> massive text you sent and you'll find the problem.
> 
> Wayne
> 
> > Caused by:
> org.sonatype.aether.resolution.ArtifactResolutionException:
> Could
> > no
> >
> >  transfer artifact
> org.safehaus.jug:jug:pom:2.0.0-osgi from/to jboss
> > (http://re
> >
> > ository.jboss.com/maven2): Access denied to:
> > http://repository.jboss.com/maven2
> >
> > org/safehaus/jug/jug/2.0.0-osgi/jug-2.0.0-osgi.pom
> ..
> >
> > Caused by:
> org.sonatype.aether.transfer.ArtifactTransferException:
> Could not
> > tr
> >
> > nsfer artifact org.safehaus.jug:jug:pom:2.0.0-osgi
> from/to jboss
> > (http://reposi
> >
> > ory.jboss.com/maven2): Access denied to:
> > http://repository.jboss.com/maven2/org
> >
> > safehaus/jug/jug/2.0.0-osgi/jug-2.0.0-osgi.pom
> 
> -
> 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: How to release a single module in a Mercurial repository?

[Mark Struberg]

hmm, I think we should remove this Exception. 
tagging a subdirectory is again only valid in very special SCMs, mainly SVN 
(don't remember how this did behave in CVS anymore).


Usually a tag is a 'name' on a certain snapshot in the whole repo. Tagging a 
repo will just give you this unique snapshot over the repo, regardless of the 
submodule you are currently in. That's a well known behaviour lots of SCMs and 
most people who are using those SCMs should certainly be aware of it.

LieGrue,
strub

--- On Sun, 3/6/11, Andreas Ebbert-Karroum 
 wrote:

> From: Andreas Ebbert-Karroum 
> Subject: Re: How to release a single module in a Mercurial repository?
> To: "Maven Users List" 
> Cc: "Olivier Lamy" 
> Date: Sunday, March 6, 2011, 8:15 PM
> Hi Oliverm
> 
> 2011/3/5 Olivier Lamy 
> 
> > @Andreas
> >
> > I see you are using scm 1.4
> >
> > 
> >   org.apache.maven.scm
> >   maven-scm-provider-hg
> >   1.4
> > 
> >
> > Can you try with 1.5-SNAPSHOT ?
> >
> 
> 
> Yes, I am using the 1.4 release, because the 1.5-Snapshot
> gave an error
> message, that it cannot tag subdirectories of the
> repository. Quote from the
> E-Mail:
> 
> The new dependencies with the snapshot release plugin also
> updates to a
> newer hg scm provider. The new hg scm provider has the
> interesting new habit
> to throw an exception, when you want to tag something,
> which does not
> concern the whole repository.
> 
> Caused by: org.apache.maven.scm.ScmException: This provider
> doesn't support
> tagging subsets of a directory
>         at
> org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77)
>         at
> org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81)
>         at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
>         ... 29 more
> 
> -- 
> Mit freundlichen Grüßen / Best regards
> 
> Andreas Ebbert-Karroum | Bereichsleiter der Agilen Software
> Factory
> 
> codecentric AG | Merscheider Straße 1 | 42699 Solingen |
> Deutschland
> tel: +49 (0) 212.23362825 | fax: +49 (0) 212.23362879 |
> mobil: +49 (0)
> 175.2664109
> www.codecentric.de | blog.codecentric.de |
> www.meettheexperts.de |
> www.more4fi.de
> 
> Sitz der Gesellschaft: Düsseldorf | HRB 63043
> Vorstand: Klaus Jäger (Vorsitzender) | Mirko Novakovic .
> Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Bernd
> Klinkmann . Jürgen
> Schütz
> 
> Diese E-Mail einschließlich evtl. beigefügter Dateien
> enthält vertrauliche
> und/oder rechtlich geschützte Informationen. Wenn Sie
> nicht der richtige
> Adressat sind oder diese E-Mail irrtümlich erhalten haben,
> informieren Sie
> bitte sofort den Absender und löschen Sie diese E-Mail und
> evtl. beigefügter
> Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder
> Öffnen evtl.
> beigefügter Dateien sowie die unbefugte Weitergabe dieser
> E-Mail ist nicht
> gestattet.
> 




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

Re: How to release a single module in a Mercurial repository?

[Mark Struberg]

hmm, looks good so far. The only thing I noticed is that the URL in the child 
module doesn't contain a trailing /:

scm:hg:https://maven-scm-provider-hg-test.googlecode.com/hg
vs 
scm:hg:https://maven-scm-provider-hg-test.googlecode.com/hg/

does this make any difference? (Shouldn't but I've seen code in maven-scm where 
it does...)

LieGrue,
strub
--- On Sat, 3/5/11, Olivier Lamy  wrote:

> From: Olivier Lamy 
> Subject: Re: How to release a single module in a Mercurial repository?
> To: "Maven Users List" 
> Date: Saturday, March 5, 2011, 4:14 PM
> @Mark I have a project here [1], I
> use for testing maven scm stuff.
> I have started testing this and  have reproduce but
> with a different error :
> 
> [INFO] EXECUTING: /bin/sh -c cd
> /home/olamy/dev/test-projects/maven-scm-provider-hg-test/my-app
> && hg
> commit --message '[maven-release-plugin] prepare release
> my-app-1.7'
> /home/olamy/dev/test-projects/maven-scm-provider-hg-test/my-app/pom.xml
> [INFO] EXECUTING: /bin/sh -c cd
> /home/olamy/dev/test-projects/maven-scm-provider-hg-test/my-app
> && hg
> push https://maven-scm-provider-hg-test.googlecode.com/hg
> [ERROR]
> EXECUTION FAILED
>   Execution of cmd : push failed with exit code: 255.
>   Working directory was:
>    
> /home/olamy/dev/test-projects/maven-scm-provider-hg-test/my-app
>   Your Hg installation seems to be valid and
> complete.
>     Hg version: 1.7.3 (OK)
> 
> Weird because the cli looks correct.
> 
> @Andreas
> 
> I see you are using scm 1.4
> 
> 
>    org.apache.maven.scm
>    maven-scm-provider-hg
>    1.4
> 
> 
> Can you try with 1.5-SNAPSHOT ?
> 
> -- 
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
> 
> [1] http://code.google.com/p/maven-scm-provider-hg-test/
> 
> 2011/3/5 Mark Struberg :
> > Andreas, it would be really fine if you could provide
> your sample project as a tar.gz or zip. Because in theory it
> should really also work with hg. The fix in MRELEASE-457
> should just allow that.
> >
> > Btw, sometimes the default behaviour of the MavenModel
>  section handling also adds some bad salt to the
> story: it currently _always_ automatically adds the
> child-modules name to the scm URL, which is ok for SVN and
> CVS but _VERY_ bad for git, hg and likes. Because in git,
> hg, etc the URL _doesn't_ change for the sub-module!
> >
> > So please before filling a Jira issue, please check if
> all your child modules contain a copy of the 
> section of the parent pom. Just copy it over to the child
> pom please!
> >
> > @Olivier, I think we should finally fix this ugly
> stuff asap. The probleme here is that the MavenModel per
> definition doen't know anything about the SCM provider
> (because that gets defined by the MavenMode) and the scm
> provider doesn't yet know anything about the Maven Model it
> is contained in. Also, the scm URL is not only used by the
> various maven-scm-providers but also by reporting etc...
> > So this could be tricky. I thought about a
> configurable 'ScmUrlRules#FIXED, SUBMODULES' which can be
> configured via a RegExp in maven settings which gets applied
> to the scm URL. Or any other kind of pulling this info out
> of the model vs scm-provider context.
> >
> > LieGrue,
> > strub
> >
> > --- On Fri, 3/4/11, Olivier Lamy 
> wrote:
> >
> >> From: Olivier Lamy 
> >> Subject: Re: How to release a single module in a
> Mercurial repository?
> >> To: "Andreas Ebbert-Karroum" 
> >> Cc: "Maven Users List" 
> >> Date: Friday, March 4, 2011, 4:53 PM
> >> Please use hg scm provider component
> >>
> >> Thanks !
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy
> >> http://www.linkedin.com/in/olamy
> >>
> >> 2011/3/4 Andreas Ebbert-Karroum :
> >> > Hi Olivier,
> >> >
> >> > I can gladly do so. Do you want me to report
> that for
> >> the
> >> > maven-release-plugin, or is that an issue
> with the hg
> >> scm provider?
> >> >
> >> > Andreas
> >> >
> >> > 2011/3/4 Olivier Lamy 
> >> >>
> >> >> Hello,
> >> >>
> >> >> Perso, I have tested MRELEASE-457 with
> git and
> >> svn.
> >> >> So it look to need some hack to work with
> the hg
> >> scm provider.
> >> >>
> >> >> Can you load a jira issue I will have a
> look ?
> >> >>
> >> >>

Re: How to release a single module in a Mercurial repository?

[Mark Struberg]

Andreas, it would be really fine if you could provide your sample project as a 
tar.gz or zip. Because in theory it should really also work with hg. The fix in 
MRELEASE-457 should just allow that.

Btw, sometimes the default behaviour of the MavenModel  section handling 
also adds some bad salt to the story: it currently _always_ automatically adds 
the child-modules name to the scm URL, which is ok for SVN and CVS but _VERY_ 
bad for git, hg and likes. Because in git, hg, etc the URL _doesn't_ change for 
the sub-module!

So please before filling a Jira issue, please check if all your child modules 
contain a copy of the  section of the parent pom. Just copy it over to the 
child pom please!

@Olivier, I think we should finally fix this ugly stuff asap. The probleme here 
is that the MavenModel per definition doen't know anything about the SCM 
provider (because that gets defined by the MavenMode) and the scm provider 
doesn't yet know anything about the Maven Model it is contained in. Also, the 
scm URL is not only used by the various maven-scm-providers but also by 
reporting etc...
So this could be tricky. I thought about a configurable 'ScmUrlRules#FIXED, 
SUBMODULES' which can be configured via a RegExp in maven settings which gets 
applied to the scm URL. Or any other kind of pulling this info out of the model 
vs scm-provider context.

LieGrue,
strub

--- On Fri, 3/4/11, Olivier Lamy  wrote:

> From: Olivier Lamy 
> Subject: Re: How to release a single module in a Mercurial repository?
> To: "Andreas Ebbert-Karroum" 
> Cc: "Maven Users List" 
> Date: Friday, March 4, 2011, 4:53 PM
> Please use hg scm provider component
> 
> Thanks !
> -- 
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
> 
> 2011/3/4 Andreas Ebbert-Karroum :
> > Hi Olivier,
> >
> > I can gladly do so. Do you want me to report that for
> the
> > maven-release-plugin, or is that an issue with the hg
> scm provider?
> >
> > Andreas
> >
> > 2011/3/4 Olivier Lamy 
> >>
> >> Hello,
> >>
> >> Perso, I have tested MRELEASE-457 with git and
> svn.
> >> So it look to need some hack to work with the hg
> scm provider.
> >>
> >> Can you load a jira issue I will have a look ?
> >>
> >> Thanks !
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy
> >> http://www.linkedin.com/in/olamy
> >>
> >> 2011/3/3 Andreas Ebbert-Karroum :
> >> > Hi,
> >> >
> >> > I still stand by my claim that the story of
> releasing a single module in
> >> > a
> >> > hg multi-module repository is currently not
> possible. Now you might say,
> >> > that this is against conventions, and you
> should always release the
> >> > whole
> >> > repository, but usage of of maven and
> mercurial differs, and after all
> >> > it's
> >> > "convention over configuration" and not
> "convention or not at all".
> >> >
> >> > In this E-Mail I will prove to you that this
> is not possible, if you
> >> > will
> >> > follow me through the following steps. If at
> any point I missed an
> >> > option I
> >> > would like you to raise your voice :)
> >> >
> >> > *Step 1*
> >> >
> >> > So, I started with a very simple multi-module
> project (/pom.xml and
> >> > /multi/pom.xml) and tried to release just a
> single module (multi). It
> >> > turned
> >> > out that this is not possible, because during
> the release:perform phase,
> >> > the
> >> > whole hg repository is checked out, and the
> build is started in the root
> >> > of
> >> > that repository.
> >> >
> >> > => Use the latest
> maven-release-plugin:2.2-SNAPSHOT in which
> >> > MRELEASE-457is
> fixed.
> >> >
> >> > *Step 2*
> >> >
> >> > The new dependencies with the snapshot
> release plugin also updates to a
> >> > newer hg scm provider. The new hg scm
> provider has the interesting new
> >> > habit
> >> > to throw an exception, when you want to tag
> something, which does not
> >> > concern the whole repository.
> >> >
> >> > Caused by: org.apache.maven.scm.ScmException:
> This provider doesn't
> >> > support
> >> > tagging subsets of a directory
> >> >        at
> >> >
> >> >
> org.apache.maven.scm.provider.hg.command.tag.HgTagCommand.executeTagCommand(HgTagCommand.java:77)
> >> >        at
> >> >
> >> >
> org.apache.maven.scm.command.tag.AbstractTagCommand.executeCommand(AbstractTagCommand.java:81)
> >> >        at
> >> >
> >> >
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
> >> >        ... 29 more
> >> >
> >> > => Update the dependencies of
> maven-release-plugin:2.2-SNAPSHOT to use
> >> > maven-scm-provider-hg:1.4
> >> >
> >> > *Step 3
> >> > *
> >> > The next step was to move the parent pom out
> of the root of the hg
> >> > repository. We have a standardized layout in
> our hg repositories (to
> >> > take
> >> > into account various tradeoffs between maven,
> m2eclipse, hudson, etc.)
> >> > that
> >> > we have all projects in directories under the
> root directory. So I tried
> >> > to
> >> > have
> >> > / root / pom.xml 

Re: maven-release-plugin multimodule creating additional subversion tags for each module

[Mark Struberg]

Hi Mirko!

If you release the whole project at once, then you obviously only get exactly 
one tag!

You'd need to run releases on each module on it's own to get the single tags. 
But I'm not sure if this is really a good thing...

What is the goal you like to achieve? What's wrong for you with that tag?

LieGrue,
strub

--- On Tue, 1/25/11, Mirko Friedenhagen  wrote:

> From: Mirko Friedenhagen 
> Subject: maven-release-plugin multimodule creating additional subversion tags 
> for each module
> To: users@maven.apache.org
> Date: Tuesday, January 25, 2011, 9:12 PM
> Hello,
> 
> Dear all,
> 
> in our company we have a policy that every released
> artifact should
> have a release tag in Subversion assuming tagging is a
> cheap operation
> in subversion.
> 
> So given a standard multimodule project:
> 
> foo/trunk/pom.xml
> (groupId=foo,artifactId=parent,version=1.0-SNAPSHOT)
> foo/trunk/core/pom.xml
> (groupId=foo,artifactId=core,parent=foo.parent:1.0-SNAPSHOT)
> foo/trunk/app1/pom.xml
> (groupId=foo,artifactId=app1,parent=foo.parent:1.0-SNAPSHOT)
> foo/trunk/app2/pom.xml
> (groupId=foo,artifactId=app2,parent=foo.parent:1.0-SNAPSHOT)
> 
> I want to have the following tags after running mvn -B
> release:prepare
> release:perform
> 
> foo/tags/parent-1.0
> foo/tags/core-1.0
> foo/tags/app1-1.0
> foo/tags/app2-1.0
> 
> Currently only foo/tags/parent-1.0 is created. Any ideas on
> how to achieve this?
> 
> Regards
> Mirko
> -- 
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/
> https://bitbucket.org/mfriedenhagen/
> 
> -
> 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: One project per package or multiple packages in same project?

[Mark Struberg]

+1 for using external 'properties'

Usually you like to produce only one WAR file and use exactly this single WAR 
file on your test box, move it further to the integration test server and then 
move it to the production server. The SHA-1 of the WAR _must_not_ change! If 
you need to rebuild a different WAR for your production server, then all the 
previously testing steps are pretty much worthless...

In my projects (using OpenWebBeans as CDI container) I use 
@ProjectStageActivated [1] for switching between configurations.

LieGrue,
strub

[1] https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage

--- On Tue, 1/25/11, Anders Hammar  wrote:

> From: Anders Hammar 
> Subject: Re: One project per package or multiple packages in same project?
> To: "Maven Users List" 
> Date: Tuesday, January 25, 2011, 11:35 AM
> Antonio is right.
> 
> This has been discussed several times. Search the archive
> for many examples
> of doing this, including using JNDI or putting a properties
> file on the
> classpath.
> 
> I understand this would require changes to your code base.
> Major changes
> possibly. But it is the right way to go. Once you have donw
> this, adding new
> environments is a small task instead of requiring a new
> build (and breaking
> close to everything Maven is about).
> 
> /Anders
> 
> On Tue, Jan 25, 2011 at 12:26, Miguel Almeida 
> wrote:
> 
> > On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli
> <
> > antonio.petre...@gmail.com>
> wrote:
> >
> > >
> > > No, he means (correct me if I am wrong) that you
> should have a war for
> > > each web application you have. Since you have
> *one* web application,
> > > one war is ok.
> > > Configuration like IP addresses, ports, etc.
> should be externalized
> > > and not put in the WAR at all.
> > >
> >
> > Externalised where exaclty? Because that's precisely
> my configuration: I
> > have one WAR and configuration is being externalised
> to profiles, like so:
> >
> > 
> >           
> dev
> >           
> 
> >               
> true
> >
> >
> > 
> jdbc:postgresql://locahost/develomentDB
> >               
> /mnt/devel/
> > ...
> >           
> 
> > 
> >
> > My original questions were, therefore:
> > a) is this the best way to keep my project?
> > b) when I package the WAR, what profile should I use?
> Or should I archive
> > project-0.0.1-dev, project-0.0.1-clientTest,
> project-0.0.1-clientProduction
> > ?
> >
> 




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

Re: Maven release:perform deploy failed access denied

[Mark Struberg]

hi!

Please look at the file permissions on your server, maybe the file got uploaded 
by someone else and you have no right to write to this directory.

To prevent such situations, one usually uses the following settings.xml 
configuration:


  yourServerId
  yourusername
  yourpassword
  0775
  0664


Rerun the release with the -X option and use | tee mvn.log to catch the full 
output of the maven run.


LieGrue,
strub

PS: I assume you substituted your servername in
Uploading: 
http://serverIp/nexus/content/groups/MyRepositories//com/project/Parent/0.0.5/Parent-0.0.5.pom
 , right?

--- On Tue, 1/18/11, jeb001  wrote:

> From: jeb001 
> Subject: Re: Maven release:perform deploy failed access denied
> To: users@maven.apache.org
> Date: Tuesday, January 18, 2011, 12:48 PM
> 
> Hum.. I tried something else, I launched the mvn:deploy
> task, and it works !!
> 
> ... I jus't don't understand... any idea ?
> -- 
> View this message in context: 
> http://maven.40175.n5.nabble.com/Maven-release-perform-deploy-failed-access-denied-tp3339497p3346122.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> -
> 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: Welcome Wayne Fay to the Maven PMC

[Mark Struberg]

Congratulations Wayne!

Keep up the good work ;)

LieGrue,
strub

--- On Sat, 1/15/11, Olivier Lamy  wrote:

> From: Olivier Lamy 
> Subject: Re: Welcome Wayne Fay to the Maven PMC
> To: "Maven Users List" 
> Date: Saturday, January 15, 2011, 11:38 AM
> Welcome aboard !
> 
> --
> Olivier
>  Le 15 janv. 2011 02:08, "Brian Fox" 
> a écrit :
> > I'm sure you all know Wayne since he's been around
> forever answering
> > user list questions. We recently voted him in both as
> a committer and
> > a PMC member, so please join me in congratulating him.
> We're secretly
> > hoping that he'll use his commit rights to start
> improving the
> > documentation since he's so good at answering
> questions ;-)
> >
> > Welcome Wayne!
> >
> > --Brian Fox
> > Apache Maven PMC Chair
> >
> >
> -
> > 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: release plugin versus dependency plugin

[Mark Struberg]

Hi Benson!

Please check the preparationGoals property in the release plugin [1]

Maybe you Please try with something like -DpreparationGoals="clean install"


LieGrue,
strub

[1] 
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#preparationGoals


--- On Thu, 12/23/10, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: release plugin versus dependency plugin
> To: "Maven Users List" 
> Date: Thursday, December 23, 2010, 6:17 PM
> Under a single aggregate project, I
> have two projects.
> 
> Project 1 builds an extra artifact with a classifier.
> 
> Project 2 uses dependency:unpack to unpack it for inclusion
> in a, yes,
> larger artifact.
> 
> All's well until I try to run the release:prepare goal, at
> which
> point, the first artifact is missing when the second
> project asks for
> it.
> 
> any ideas? Why is the :prepare run different?
> 
> 
> [INFO] Embedded error: Unable to download the artifact from
> any repository
> [INFO]
> [INFO] Try downloading the file manually from the project
> website.
> [INFO]
> [INFO] Then, install it using the command:
> [INFO]     mvn install:install-file
> -DgroupId=com.basistech.jug
> -DartifactId=rlp-gate-plugin -Dversion=8
> -Dclassifier=gate-plugin
> -Dpackaging=zip -Dfile=/path/to/file
> [INFO]
> [INFO] Alternatively, if you host your own repository you
> can deploy
> the file there:
> [INFO]     mvn deploy:deploy-file
> -DgroupId=com.basistech.jug
> -DartifactId=rlp-gate-plugin -Dversion=8
> -Dclassifier=gate-plugin
> -Dpackaging=zip -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> [INFO]
> [INFO]
> [INFO]   com.basistech.jug:rlp-gate-plugin:zip:8
> 
> -
> 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: maven sql plugin and clobs

[Mark Struberg]

How did you generate/create the clob script?

I'm using clobs in mysql migrationdata imports and they work fine. I'm using 
mysqldump to create the sql file which correctly escapes those values.

I assume you have Oracle 11? (up 2 Oracle 10 it was imo only able to export to 
their own bin format)


LieGrue,
strub

--- On Wed, 12/22/10, Jason Perry  wrote:

> From: Jason Perry 
> Subject: maven sql plugin and clobs
> To: users@maven.apache.org
> Date: Wednesday, December 22, 2010, 8:38 PM
> Hi,
> 
> I am running into a problem when trying trying to import a
> .sql file that
> has clob data.  Anyone run into this or know of a
> workaround?  Here is the
> failure:
> 
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] ORA-06550: line 6, column 15:
> PLS-00103: Encountered the symbol "
> 
> 
>  expecting one of the
> following:
> 
>    ( - + case mod new not null  identifier>
>     delimited-identifier>  avg
>    count current exists max min prior sql
> stddev sum variance
>    execute forall merge time timestamp
> interval date
>     specification>
>      string> pipe
>     literal
> 
> Thanks,
>     -- Jay
> 




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

Re: classifiers versus dependencies

[Mark Struberg]

if this zip file only contains other jar artifacts, then you can also use the 
maven-shade-plugin and produce a reduced pom [1]

Btw, does the maven-shade-plugin already has an OSGi merging filter? 

LieGrue,
strub


[1] 
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#createDependencyReducedPom




- Original Message 
> From: Stephen Connolly 
> To: Maven Users List 
> Sent: Sat, August 21, 2010 9:02:20 AM
> Subject: Re: classifiers versus dependencies
> 
> the correct solution is to mark all its dependencies as  
>provided
> 
> otherwise if you try your suggestion  you will have issues with the
> preparation goals when you run  release:prepare
> 
> -Stephen
> 
> On 20 August 2010 13:47, Benson Margulies   wrote:
> >  I have a zip file built with the assembly plugin. I list it as a
> >  dependency in a project so that I can in turn include it in another
> >  assembly.
> >
> > I got a surprise. mvn dependency:tree shows that it  has dependencies
> > -- all the dependencies of its parent.
> >
> >  This is particularly sideways since it was carefully shaded to avoid
> >  dependencies.
> >
> > I think that the solution to my problem is to use  dependency:copy on
> > the artifactId and  in the second  assembly instead of a
> > dependencySet, but I thought I would note this for  posterity.
> >
> >  -
> > 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
> 
> 


  

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

Re: Releasing only one (sub)module within an SCM tree

[Mark Struberg]

Hi Johannes, Olivier!

Took me some time to find a few free minutes but now I've coded the support for 
releasing child modules into maven-release-manager. 

Please see MRELEASE-457 for a patch which needs to be reviewed before I'll 
check 
it in.

LieGrue,
strub



- Original Message 
> From: Johannes Schneider 
> To: Maven Users List 
> Sent: Fri, August 6, 2010 11:56:03 AM
> Subject: Re: Releasing only one (sub)module within an SCM tree
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 08/06/2010 10:53 AM,  Olivier Lamy wrote:
> > Hi,
> > Do you have a scm element in your module  ?
> 
> I tried it. At the moment I just have an scm element in my  parent.
> 
> > Just to be sure your tree is similar to :  
>http://github.com/olamy/scm-git-test ?
> > And you want to release only  my-app ?
> 
> Yes, exactly. That is the scenario. Now I just want to remove  the
> modules section from the parent...
> 
> > By the way it could be  fixed if there was a way to do something like
> > git clone g...@github.com:olamy/scm-git-test.git/my-app
> 
> Yes.  But that is not possible... (Un)fortunately...
> 
> Maven is build with  Subversion in mind... Therefore the problems.
> 
> 
> Johannes
> 
> > 
> > Or doing some hackhish stuff for git in the release plugin.
> > 
> > Can you load an issue on this ? (IHMO it looks to be reasonnable  to
> > add hack for such case)
> > 
> > 2010/8/5 Johannes Schneider  :
> >  Hi,
> > 
> > I have such a structure within my Git tree:
> > 
> > daParent
> >- moduleA
> > - moduleB
> >- ...
> > 
> > Until today I released all modules together. This worked like a  charm.
> > 
> > Now I want to release the modules independently. But  that does not work.
> > 
> > I have removed the "modules" section from  "daParent" and have been able
> > to release that artifact  successfully.
> > Now I upgraded the parent version within moduleA and  moduleB manually.
> > 
> > But releasing moduleA does *not* work  now.
> > 
> > 
> > release:prepare works as expected, but  release:perform checks out the
> > the tagged version and tries to release  "/pom.xml".
> > Of course this pom is the pom of "daParent"...
> > 
> > Since I am using Git I can't simply add a corrected scm tag to  moduleA
> > and moduleB...
> > 
> > 
> > So how could I solve  that? I experimented with
> > -DpomFileName=moduleA/pom.xml but that did not  work
> > Any ideas are welcome...
> > 
> > 
> > 
> >  Thanks,
> > 
> > Johannes
> > 
> > 
> >>
> -  -
> To  unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For  additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> 
> -  -- 
> Johannes Schneider - blog.cedarsoft.com
> -BEGIN PGP  SIGNATURE-
> Version: GnuPG v1.4.10  (GNU/Linux)
> 
> iQEcBAEBAgAGBQJMW9wwAAoJEAytD9R7Qv6dhWoH/j+KXnAlzOIwSqAXjQzvIrJn
> B3VVp61ltm5kBLpl63aP0sIrWMde7QboSfcTjnsl5KA1NXvTm2XaybpNnmyJVXQs
> YTI1J2h7/BoCIxeSzdN02mB6ptjZIkDwcAgjZkhUNTA41Q+3CoKE2lVwpYcjdTj8
> /gc0qj72Tfxw6SgzxVo5uWTxf7TPLxoXshFFAkj8xXtkpYEfUxvu0mlf/VZYVJp4
> ZWlBtD6u9kldNgfWtSEp3JJiLEeSi8PW3Ym8vQCVeAh5UAgzqtiTns5NPJEbE4vv
> Tf46HLx55RY6nNI5XmbDr5xLzGMeIVbV3ehobsz9msZzqatmq9FIiTpFLut13b0=
> =eAyX
> -END  PGP  SIGNATURE-
> 
> -
> 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: war dependent on another war

[Mark Struberg]

checked our Jira and found http://jira.codehaus.org/browse/MWAR-73 from 2006. 
I'll check if parts are still missing and fix it or set the jira to resolved if 
all is ok nowadays.

LieGrue,
strub



- Original Message 
> From: Mark Struberg 
> To: Maven Users List 
> Sent: Sun, August 8, 2010 11:48:57 AM
> Subject: Re: war dependent on another war
> 
> Hi!
> 
> Use the 'archiveClasses' and 'attachClasses' [1] options of the  
>maven-war-plugin 
>
> in your first WAR file. This way all your classes of this  war will get jared 
>and 
>
> used this way in WEB-INF/lib as jar instead of  WEB-INF/classes. The 2nd 
> option 
>
> will tell maven to treat this jar as  'attached artifact' [2]. If you look at 
> your local repository in  ~/.m2/repository/... for your WAR, you will see a 
> '..-webclasses.jar' (not  100% sure about the qualifier name, this got 
> changed 

> since I first hacked  this years ago). You can then use this jar as 
> dependency 

> with this  classifier. The groupId and artifactId are the ones from your WAR 
> file.
> 
> 
> LieGrue,
> strub
> 
> [1]  
>http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses
> [2] 
>http://docs.codehaus.org/display/MAVEN/Packaging+vs+Type+-+Derived+and+Attached+Artifacts
>s
> 
> 
> 
> - - Original Message 
> > From: Aneesh K raj 
> >  To: users@maven.apache.org
> > Sent:  Sun, August 8, 2010 11:39:00 AM
> > Subject: war dependent on another  war
> > 
> > hi,
> > 
> > i am having trouble having classes of  a war in the classpath for  another 
> war..
> > am using maven 2.x  jdk1.5 windows 7
> > 
> > i had added the  below to the pom.xml for  the dependent war but it didnt 
>work  
>
> >out..
> > 
> > 
> >   ..
> >   ..
> >   ..
> >war
> >..
> > 
> 
> 
>   
> 
> -
> 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: war dependent on another war

[Mark Struberg]

Hi!

Use the 'archiveClasses' and 'attachClasses' [1] options of the 
maven-war-plugin 
in your first WAR file. This way all your classes of this war will get jared 
and 
used this way in WEB-INF/lib as jar instead of WEB-INF/classes. The 2nd option 
will tell maven to treat this jar as 'attached artifact' [2]. If you look at 
your local repository in ~/.m2/repository/... for your WAR, you will see a 
'..-webclasses.jar' (not 100% sure about the qualifier name, this got changed 
since I first hacked this years ago). You can then use this jar as dependency 
with this classifier. The groupId and artifactId are the ones from your WAR 
file.


LieGrue,
strub

[1] http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#attachClasses
[2] 
http://docs.codehaus.org/display/MAVEN/Packaging+vs+Type+-+Derived+and+Attached+Artifacts



- Original Message 
> From: Aneesh K raj 
> To: users@maven.apache.org
> Sent: Sun, August 8, 2010 11:39:00 AM
> Subject: war dependent on another war
> 
> hi,
> 
> i am having trouble having classes of a war in the classpath for  another 
war..
> am using maven 2.x jdk1.5 windows 7
> 
> i had added the  below to the pom.xml for the dependent war but it didnt work 
>  
>out..
> 
> 
>   ..
>   ..
>   ..
>   war
>..
> 


  

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

Re: Unable to find resource 'org.glassfish:javax.ejb:pom:3.0'

[Mark Struberg]

If you need it for a company, then I would highly recommend a repository 
manager like Nexus or Archiva + a decent data backup for the accumulated repo.
You will route () all your requests to public repos through your repo 
manager and thus it will 'cache' your artifacts. So even if the repo on 
java.net looses some artifacts, you will have a backup of it available in your 
companies repo manager. 

This will not work for 'public' projects though...

LieGrue,
strub



- Original Message 
> From: Thomas Porschberg 
> To: users@maven.apache.org
> Sent: Thu, July 1, 2010 11:18:53 AM
> Subject: Re: Unable to find resource 'org.glassfish:javax.ejb:pom:3.0'
> 
> I think org.glassfish.embedded:glassfish-embedded-all:jar is obsolete
now, 
> e.g. javax.ejb.embeddable.EJBContainer is contained in
javax.ejb.jar.
I 
> drop the entry from my  list and it worked.

However the 
> question how to get reliable maven repositories is still
important for 
> me.

Thomas


Am Thu, 1 Jul 2010 11:03:40 +0200
schrieb 
> Thomas Porschberg <
> href="mailto:porschb...@osp-dd.de";>porschb...@osp-dd.de>:

> 
> 
> Ok, I understand your concerns but what would be a reliable 
> repository
> which provides:
> 
> >snip
> 
> Missing:
> --
> 1) 
> org.glassfish.embedded:glassfish-embedded-all:jar:3.0
> >snip
> 
> 
> ?
> 
> Thomas
> 
> Am Thu, 1 Jul 2010 09:41:13 
> +0100
> schrieb Stephen Connolly <
> ymailto="mailto:stephen.alan.conno...@gmail.com"; 
> href="mailto:stephen.alan.conno...@gmail.com";>stephen.alan.conno...@gmail.com>:
> 
> 
> > Well I consider that to fall under immutability of 
> releases:
> > 
> > 1. don't delete released artifacts (except 
> possibly when there are
> > legal issues)
> > 2. don't change 
> released artifacts.
> > 
> > But I did not know about that 
> example!
> > 
> > -Stephen
> > 
> > On 1 
> July 2010 09:31, Mark Struberg <
> href="mailto:strub...@yahoo.de";>strub...@yahoo.de> wrote:
> > 
> 
> > > to back Stephens word: it's even worse - they recently 
> dropped
> > > 'old' JSF-1 artifacts from their repo without any 
> noticing...
> > >
> > > So really only use the 
> target="_blank" href="http://java.net";>java.net maven repo via a repo 
> manager like
> > > Nexus or Archiva.
> > >
> > 
> > LieGrue,
> > > strub
> > >
> > 
> >
> > >
> > > - Original Message 
> 
> > > > From: Stephen Connolly <
> ymailto="mailto:stephen.alan.conno...@gmail.com"; 
> href="mailto:stephen.alan.conno...@gmail.com";>stephen.alan.conno...@gmail.com>
> 
> > > > To: Maven Users List <
> ymailto="mailto:users@maven.apache.org"; 
> href="mailto:users@maven.apache.org";>users@maven.apache.org>
> > 
> > > Sent: Thu, July 1, 2010 9:09:47 AM
> > > > Subject: Re: 
> Unable to find resource
> > > > 
> 'org.glassfish:javax.ejb:pom:3.0'
> > > >
> > > > 
> I am going to state this once and only once:
> > >
> > 
> >"Friends don't
> > > > let friends use the 
> java.net maven
> > > > repositories" (at
> > > least 
> without protection (e.g. a maven repository
> > > > 
> manager))
> > >
> > > It's fine for following a 
> tutorial, but don't keep the bad
> > > > habit when you
> 
> > > start writing real code.
> > >
> > > 
> -Stephen
> > >
> > > P.S.
> > >
> > 
> > > the reason why you should not use the java.net repos is that
> 
> > > > they do not
> > > have/enforce the following 
> policies:
> > >* immutability of
> > > 
> > releases
> > >* single origin of artifacts (i.e. 
> if a GAV coordinate
> > > > exists on
> > > central, 
> then the artifact at that GAV should either not be
> > > 
> present
> > > > in the
> > > java.net repo 
> (preferred) or else it should be exactly, byte for
> > > 
> byte,
> > > > the
> > > same as the artifact on 
> central (less preferred))
> > >*
> > > 
> > other process issues too complex to explain to somebody new to
> > 
> > > maven
> > >
> > > On 1
> > > > 
> July 2010 07:38, Thomas Por

Re: Unable to find resource 'org.glassfish:javax.ejb:pom:3.0'

[Mark Struberg]

to back Stephens word: it's even worse - they recently dropped 'old' JSF-1 
artifacts from their repo without any noticing...

So really only use the java.net maven repo via a repo manager like Nexus or 
Archiva.

LieGrue,
strub



- Original Message 
> From: Stephen Connolly 
> To: Maven Users List 
> Sent: Thu, July 1, 2010 9:09:47 AM
> Subject: Re: Unable to find resource 'org.glassfish:javax.ejb:pom:3.0'
> 
> I am going to state this once and only once:

"Friends don't 
> let friends use the java.net maven 
> repositories" (at
least without protection (e.g. a maven repository 
> manager))

It's fine for following a tutorial, but don't keep the bad 
> habit when you
start writing real code.

-Stephen

P.S.
  
> the reason why you should not use the java.net repos is that they do 
> not
have/enforce the following policies:
* immutability of 
> releases
* single origin of artifacts (i.e. if a GAV coordinate 
> exists on
central, then the artifact at that GAV should either not be present 
> in the
java.net repo (preferred) or else it should be exactly, byte for byte, 
> the
same as the artifact on central (less preferred))
* 
> other process issues too complex to explain to somebody new to maven

On 1 
> July 2010 07:38, Thomas Porschberg <
> href="mailto:porschb...@osp-dd.de";>porschb...@osp-dd.de> 
> wrote:

> I solved the problem with 
> http://www.mvnbrowser.com
>
> and
>
> 
> 
>  glassfish
>  
> Maven Repository Glassfish
>  
> default
>  
> http://download.java.net/maven/glassfish
>  
> 
>  
> false
>  
> 
> 
>
> Thomas
>
> Am Wed, 30 Jun 2010 
> 18:00:01 +0200
> schrieb Thomas Porschberg <
> ymailto="mailto:porschb...@osp-dd.de"; 
> href="mailto:porschb...@osp-dd.de";>porschb...@osp-dd.de>:
>
> 
> > Hi,
> >
> > I'm now in chapter 6 of "Java EE 6 Platform 
> with GlassFish 3"
> > and I try to build the example with mvn.
> 
> >
> > In my pom.xml there is:
> >
> > ...
> 
> > 
> >  
> org.glassfish
> >  
> javax.ejb
> >  
> 3.0
> > 
> > 
> 
> >  
> org.glassfish.embedded
> >  
> glassfish-embedded-all
> >  
> 3.0
> >  
> test
> > 
> > 
> ...
> >
> > but a "mvn package" gives me:
> >
> 
> >
> > Downloading:
> >
> 
> http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/rt/eclipselink/maven.repo/org/glassfish/javax.ejb/3.0/javax.ejb-3.0.pom
> 
> > [INFO] Unable to find resource 'org.glassfish:javax.ejb:pom:3.0' in
> 
> > repository EclipseLink Repo
> > (
> 
> http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/rt/eclipselink/maven.repo
> 
> )
> > Downloading:
> >
> 
> http://repo1.maven.org/maven2/org/glassfish/javax.ejb/3.0/javax.ejb-3.0.pom
> 
> > [INFO] Unable to find resource 'org.glassfish:javax.ejb:pom:3.0' in
> 
> > repository central (http://repo1.maven.org/maven2) Downloading:
> 
> >
> 
> http://download.java.net/maven/2/org/glassfish/javax.ejb/3.0/javax.ejb-3.0.pom
> 
> > [INFO] Unable to find resource 'org.glassfish:javax.ejb:pom:3.0' in
> 
> > repository 
> href="http://maven2-repository.dev.java.net";>maven2-repository.dev.java.net
> 
> > (http://download.java.net/maven/2)
> >
> > Is there a 
> maven2 repository outside which provides the glassfish
> > 
> jars?
> >
> > I have also a running glassfish server on my 
> machine but is it the
> > right way to install the jars 
> manually?
> >
> > Best regards
> > Thomas
> 
> >
>
>
>
> --
> 
> _
>
> Thomas 
> Porschberg
> Otto Group · GroupTechnologyPartner - Dresden (GTP)
> 
> Softwareentwickler · Lokale Logistik · FI-IS-LL
>
> 
> GroupTechnologyPartner - Dresden GmbH · Freiberger Straße 35 · 01067
> 
> Dresden Telefon +49 (0) 351 497 23 158 · Fax +49 (0) 351 497 23 119
> 
> ymailto="mailto:porschb...@osp-dd.de"; 
> href="mailto:porschb...@osp-dd.de";>porschb...@osp-dd.de · 
> href="http://www.ottogroup.com";>www.ottogroup.com 
> 
> 
> _
> AG Dresden, HRB 
> 2475
> Geschäftsführer: Dr. Thomas Tribius, Martin Mildner
>
> 
> -
> To 
> unsubscribe, e-mail: 
> href="mailto:users-unsubscr...@maven.apache.org";>users-unsubscr...@maven.apache.org
> 
> For additional commands, e-mail: 
> href="mailto:users-h...@maven.apache.org";>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: multi modules, scm and release plugin

[Mark Struberg]

>>> trunk/
>>>  |-- pom.xml
>>>  |-- parent/
>>>  | `-- pom.xml
>>>  |-- module1/
>>>  | `-- pom.xml
>>>  |-- ..
>>>  `-- modulen/
>>>`-- pom.xml

> >>> The pom-parent of trunk/pom.xml is
> trunk/parent/pom.xml.

Why not let trunk/parent/pom.xml point to trunk/pom.xml as parent? 
And trunk/module1/pom.xml youle point to trunk/parent/pom.xml as parent.

Then you should be able to release your project from trunk.

This used to work for me.

LieGrue,
strub


--- On Sun, 5/23/10, Juven Xu  wrote:

> From: Juven Xu 
> Subject: Re: multi modules, scm and release plugin
> To: "Maven Users List" 
> Date: Sunday, May 23, 2010, 9:23 AM
> I met the same issue, and created a
> ticket:
> http://jira.codehaus.org/browse/MRELEASE-562
> 
> 2010/4/19 Thomas Scheffler 
> 
> > Am 19.04.2010 12:47, schrieb Stephen Connolly:
> >
> >  You need to run the release from the aggregator
> pom.  not from the parent.
> >>
> >
> > That was exactly the way I was doing it.
> >
> >
> >  The SCM information will effectively be ignored
> by the release plugin in
> >> all
> >> but the aggregator root.
> >>
> >> But you will want the SCM info in each project so
> that the project site
> >> will
> >> contain the correct information
> >>
> >
> > Than it should have worked for me, but it wasn't. Do
> you have a project
> > like this? I mean with parent module != aggregator
> module?
> >
> > regards
> >
> > Thomas
> >
> >
> >  2010/4/19 Thomas Scheffler
> >>
> >>  Hi,
> >>>
> >>> after migrating our old ant build system to
> maven our first non-SNAPSHOT
> >>> release is planned. But I have difficulties to
> get it work with the
> >>> release
> >>> plugin.
> >>>
> >>> SVN layout is this:
> >>>
> >>> branches/
> >>> tags/
> >>> trunk/
> >>>  |-- pom.xml
> >>>  |-- parent/
> >>>  |     `-- pom.xml
> >>>  |-- module1/
> >>>  |     `-- pom.xml
> >>>  |-- ..
> >>>  `-- modulen/
> >>>        `-- pom.xml
> >>>
> >>>
> >>> The pom-parent of trunk/pom.xml is
> trunk/parent/pom.xml.
> >>>
> >>> For parent and module1-modulen the scm-URLs
> are defined in the pom.xml of
> >>> parent like this:
> >>>
> >>>
> >>> 
> >>> 
> scm:svn:file:///svn/trunk/${project.artifactId}
> >>>
> >>>
> >>>
> >>>
> scm:svn:file:///svn/trunk/${project.artifactId}
> >>> 
> >>>
> >>> in trunk/pom.xml like this:
> >>>
> >>> 
> >>> 
> scm:svn:file:///svn/trunk
> >>> 
> scm:svn:file:///svn/trunk
> >>> 
> >>>
> >>> No with that the generated sites for all
> modules will link to the correct
> >>> SVN-URL. But after a
> >>> "mvn release:prepare"
> >>> the repository layout is wrong
> >>>
> >>> branches/
> >>> tags/
> >>>  `-- release-1.0
> >>>        |-- branches
> >>>        |-- tags
> >>>        `-- trunk
> >>> trunk/
> >>>
> >>> The release plugin did not copied the content
> of the trunk folder to
> >>> tags/release-1.0 but the content of the
> parent-folder.
> >>>
> >>> So how do I have to configure the scm/release
> plugins to get this done
> >>> correctly?
> >>>
> >>> Regards,
> >>>
> >>> Thomas
> >>>
> >>
> >
> -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> 
> 
> -- 
> - juven
> 




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

Re: New PMC Member

[Mark Struberg]

Great News!

Congratulations Paul!

LieGrue,
strub

--- On Fri, 5/14/10, Brian Fox  wrote:

> From: Brian Fox 
> Subject: New PMC Member
> To: "Maven Developers List" , "Maven Users List" 
> 
> Date: Friday, May 14, 2010, 9:34 PM
> The Maven PMC recently voted to
> invite Paul Gier to join us as a
> member of the PMC Committee. He accepted and is now
> officially part of
> the Maven PMC. Congratulations Paul!
> 
> If you'd like to read more about what his exactly means,
> take a look
> at http://www.apache.org/foundation/how-it-works.html
> 
> --Brian Fox
> Maven PMC Chair.
> 
> -
> 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: Problem with wagon-scm and gitexe

[Mark Struberg]

Kathryn, I think there is a conceptional misunderstanding here.

Subversion is actually almost the ONLY SCM which has different URLs on 
different branches. 

Usually the version gets set via the -DscmVersion parameter which transfers 
into the ScmVersion parameter in various functions of the maven-scm-api!

Your attempt with first determining/setting the branch with native git commands 
would actually work with git, but I'd prefer to give wagon-scm the branch as 
parameter and use that inside the code.

txs and LieGrue,
strub

--- Kathryn Huxtable  schrieb am Fr, 2.4.2010:

> Von: Kathryn Huxtable 
> Betreff: Re: Problem with wagon-scm and gitexe
> An: "Maven Users List" 
> Datum: Freitag, 2. April, 2010 18:56 Uhr
> Here's an alternative script:
> 
> mkdir ${checkoutDirectory}
> cd ${checkoutDirectory}
> git init
> git remote add -t ${siteBranch} origin ${gitRepoUrl}
> git fetch
> git checkout ${siteBranch}
>  for the .git subdirectory, with the site docs>
> git add .
> git commit -a -m "Deploy site documentation"
> git push
> rm -Rf ${checkoutDirectory}
> 
> -K
> 
> On Apr 2, 2010, at 11:28 AM, Kathryn Huxtable wrote:
> 
> > So looking at the git SCM code (git-commons and
> gitexe) and at the wagon-scm code, the problem I see is that
> there is no syntax in the git SCM url to specify a branch to
> which to deploy the site. Not a surprise, since git
> generally wants to clone an entire repository and then push
> and pull things.
> > 
> > The desired process would be something along the lines
> of the following. (In UN*X-y/scripty/Velocity-y format.)
> > 
> >  mkdir ${checkoutDirectory}
> >  cd ${checkoutDirectory}
> >  git init
> >  git remote add origin ${gitRepoUrl}
> >  git pull origin refs/heads/${siteBranch}
> >   directory, except for the .git subdirectory, with the site
> docs>
> >  git add .
> >  git commit -a -m "Deploy site documentation."
> >  git push origin master:${siteBranch}
> >  rm -Rf ${checkoutDirectory}
> > 
> > This works.
> > 
> > Obviously, we wouldn't want to mess up the git SCM for
> other uses. Does the release plugin use the wagon? I
> *really* don't want to end up looking at all the Maven
> source code.
> > 
> > Any ideas on where changes need to be made? In
> wagon-scm? In gitexe or git-commons?
> > 
> > I see no way to configure wagons, which I find a bit
> of a lack. I suppose the URL structure and username/password
> info in settings.xml is supposed to take care of everything.
> Should there be a "branch" element in the git scm url
> structure a la the "module" element in CVS scm urls?
> > 
> > -K
> > 
> > On Apr 1, 2010, at 4:24 PM, Kathryn Huxtable wrote:
> > 
> >> Yeah, that's more or less what I mean. -K
> >> 
> >> On Apr 1, 2010, at 4:09 PM, Mark Struberg wrote:
> >> 
> >>> I honestly doubt that wagon-scm + CVS
> currently works when using branches (from glimpsing at the
> sources).
> >>> 
> >>> And I'm not sure what you mean with forking
> it. Wouldn't it be much easier to simply checkout wagon-scm
> and if you found a way to provide the branch as ScmVersion
> (ScmBranch and ScmTag are subclassses of ScmVersion [3]),
> then simply open a Jira issue and add your changes as patch.
> Patches are always highly welcome :)
> >>> 
> >>> txs and LieGrue,
> >>> strub
> >>> 
> >>> [3] 
> >>> http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html
> >>> 
> >>> 
> >>> --- Kathryn Huxtable 
> schrieb am Do, 1.4.2010:
> >>> 
> >>>> Von: Kathryn Huxtable 
> >>>> Betreff: Re: Problem with wagon-scm and
> gitexe
> >>>> An: "Maven Users List" 
> >>>> Datum: Donnerstag, 1. April, 2010 22:43
> Uhr
> >>>> Thanks, Mark,
> >>>> 
> >>>> These are good points.
> >>>> 
> >>>> I'm thinking that the issues are in
> wagon-scm, which is
> >>>> listed as being "in progress", so I can't
> really expect
> >>>> perfection. And they *do* say it's only
> been tested with svn
> >>>> and cvs. I'm thinking that I may be
> modding wagon-svn, more
> >>>> to see what's going on than to fork a
> project.
> >>>> 
> >>>> All of this is by the way. I really should
> be working on my
> >>>> project, not fiddling with t

Re: Problem with wagon-scm and gitexe

[Mark Struberg]

I honestly doubt that wagon-scm + CVS currently works when using branches (from 
glimpsing at the sources).

And I'm not sure what you mean with forking it. Wouldn't it be much easier to 
simply checkout wagon-scm and if you found a way to provide the branch as 
ScmVersion (ScmBranch and ScmTag are subclassses of ScmVersion [3]), then 
simply open a Jira issue and add your changes as patch. Patches are always 
highly welcome :)

txs and LieGrue,
strub

[3] http://maven.apache.org/scm/apidocs/org/apache/maven/scm/ScmBranch.html


--- Kathryn Huxtable  schrieb am Do, 1.4.2010:

> Von: Kathryn Huxtable 
> Betreff: Re: Problem with wagon-scm and gitexe
> An: "Maven Users List" 
> Datum: Donnerstag, 1. April, 2010 22:43 Uhr
> Thanks, Mark,
> 
> These are good points.
> 
> I'm thinking that the issues are in wagon-scm, which is
> listed as being "in progress", so I can't really expect
> perfection. And they *do* say it's only been tested with svn
> and cvs. I'm thinking that I may be modding wagon-svn, more
> to see what's going on than to fork a project.
> 
> All of this is by the way. I really should be working on my
> project, not fiddling with tools, but fiddling with tools is
> fun sometimes.
> 
> -K
> 
> On Apr 1, 2010, at 3:37 PM, Mark Struberg wrote:
> 
> > Kathryn, 
> > 
> > I haven't used wagon-scm, so I can only make vague
> assumptions.
> > Basically all the branches and tag stuff should be
> working in maven-scm-provider-gitexe. But I'm not sure how
> wagon-scm tells us what branch it likes to use.
> > 
> > From looking at the source [1] I only can see that all
> ScmVersion parameters are always given as null. So I'm not
> sure if that could work at all.
> > 
> > Please keep in mind that SVN is really exceptional
> with handling branches by copying the trunk to a new
> location. This way you get an own URL which you won't get in
> most other SCMs like CVS, PVCS, git or hg. In fact SVN
> doesn't have a 'real' branch and tag concept but internally
> always performs a full shallow copy.
> > 
> > So it would be interesting if this would also work
> e.g. with CVS.
> > 
> > LieGrue,
> > strub
> > 
> > [1] 
> > http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup
> > 
> > --- Kathryn Huxtable 
> schrieb am Do, 1.4.2010:
> > 
> >> Von: Kathryn Huxtable 
> >> Betreff: Re: Problem with wagon-scm and gitexe
> >> An: "Maven Users List" 
> >> Datum: Donnerstag, 1. April, 2010 19:21 Uhr
> >> Since it seems to be my practice to
> >> have second thought after sending a message, I'll
> add that I
> >> can check out the gh-pages branch of my git
> repository into
> >> a separate directory and deploy there using a
> "file:" URL
> >> and then commit that and push it.
> >> 
> >> That works. I just think it should be able to be
> >> automated.
> >> 
> >> -K
> >> 
> >> On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable
> wrote:
> >> 
> >>> I know the docs say that wagon-scm has only
> been
> >> tested with CVS and Subversion, and I've run it
> with
> >> Subversion successfully.
> >>> 
> >>> Is anyone working on getting it to work with
> Git, or
> >> does it already?
> >>> 
> >>> I created a very simply project with a README
> and a
> >> pom.xml and nothing else. It's at
> >>> 
> >>>     http://github.com/khuxtable/test-project
> >>> 
> >>> It uses versions 1.3 of the gitexe and
> >> scm-manager-plexus extensions and version
> 1.0-beta-6 of the
> >> scm wagon.
> >>> 
> >>> What I would like to do is deploy my site docs
> (all
> >> generated by the site plugin) to the gh-pages
> branch of the
> >> git repository. I don't see any way in the Git SCM
> URL
> >> structure to specify a branch. If there was a way
> to do this
> >> it would be cool.
> >>> 
> >>> But at the moment, with the URL
> >>> 
> >>>     scm:git:ssh://g...@github.com/khuxtable/test-project.git
> >>> 
> >>> I get the following:
> >>> 
> >>> [INFO] [site:deploy {execution: default-cli}]
> >>>
> scm:git:ssh://github.com/khuxtable/test-project.git -
> >> Session: Opened  
> >>> Uploading: . to

Re: mvn release:prepare using git, fatal: pom.xml is outside repository

[Mark Struberg]

No idea, could just guess.

1st idea: Sometimes there are still problems with spaces on windows 
directories. can you please move the directory to c:\develop or something?

if that doesn't work then please post a mvn -X log.

txs and LieGrue,
strub

--- Ricky Clarkson  schrieb am Di, 30.3.2010:

> Von: Ricky Clarkson 
> Betreff: Re: mvn release:prepare using git, fatal: pom.xml is outside  
> repository
> An: "Maven Users List" 
> Datum: Dienstag, 30. März, 2010 15:27 Uhr
> Hi Mark,
> 
> ./native-launcher/pom.xml
> ./skytab/src/main/assembly/bin.xml
> ./skytab/src/main/java/uk/org/netvu/skytab/SkyTab.java
> ./skytab/pom.xml
> ./pom.xml
> 
> I start my mvn release:prepare from the top of that (. in
> the listing above).
> 
> Thanks,
> Ricky.
> 
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1928 706373
> Skype: ricky_clarkson
> Google Talk: ricky.clark...@gmail.com
> Google Wave: ricky.clark...@googlewave.com
> 
> 
> 
> On 30 March 2010 13:43, Mark Struberg 
> wrote:
> > Can you post a tree of your project structure?
> >
> > And from where in the project tree do you start the
> release?
> >
> > txs,
> > strub
> >
> > --- Ricky Clarkson 
> schrieb am Di, 30.3.2010:
> >
> >> Von: Ricky Clarkson 
> >> Betreff: mvn release:prepare using git, fatal:
> pom.xml is outside repository
> >> An: "Maven Users List" 
> >> Datum: Dienstag, 30. März, 2010 14:21 Uhr
> >> Hi,
> >>
> >> I'm trying to tag a release using mvn
> release:prepare, and
> >> I see that
> >> a child module's pom.xml cannot be committed:
> >>
> >> The git-add command failed.
> >> Command output:
> >> fatal: 'C:\Documents and
> >> Settings\Ricky\SkyTab\skytab\pom.xml' is
> >> outside repository
> >>
> >> Any suggestions?
> >>
> >> Thanks,
> >> Ricky.
> >>
> >> --
> >> Ricky Clarkson
> >> Java and Scala Programmer, AD Holdings
> >> +44 1928 706373
> >> Skype: ricky_clarkson
> >> Google Talk: ricky.clark...@gmail.com
> >> Google Wave: ricky.clark...@googlewave.com
> >>
> >>
> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> > __
> > Do You Yahoo!?
> > Sie sind Spam leid? Yahoo! Mail verfügt über einen
> herausragenden Schutz gegen Massenmails.
> > http://mail.yahoo.com
> >
> >
> -
> > 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
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

Re: Problem with wagon-scm and gitexe

[Mark Struberg]

Kathryn, 

I haven't used wagon-scm, so I can only make vague assumptions.
Basically all the branches and tag stuff should be working in 
maven-scm-provider-gitexe. But I'm not sure how wagon-scm tells us what branch 
it likes to use.

From looking at the source [1] I only can see that all ScmVersion parameters 
are always given as null. So I'm not sure if that could work at all.

Please keep in mind that SVN is really exceptional with handling branches by 
copying the trunk to a new location. This way you get an own URL which you 
won't get in most other SCMs like CVS, PVCS, git or hg. In fact SVN doesn't 
have a 'real' branch and tag concept but internally always performs a full 
shallow copy.

So it would be interesting if this would also work e.g. with CVS.

LieGrue,
strub

[1] 
http://svn.apache.org/viewvc/maven/wagon/trunk/wagon-providers/wagon-scm/src/main/java/org/apache/maven/wagon/providers/scm/ScmWagon.java?view=markup

--- Kathryn Huxtable  schrieb am Do, 1.4.2010:

> Von: Kathryn Huxtable 
> Betreff: Re: Problem with wagon-scm and gitexe
> An: "Maven Users List" 
> Datum: Donnerstag, 1. April, 2010 19:21 Uhr
> Since it seems to be my practice to
> have second thought after sending a message, I'll add that I
> can check out the gh-pages branch of my git repository into
> a separate directory and deploy there using a "file:" URL
> and then commit that and push it.
> 
> That works. I just think it should be able to be
> automated.
> 
> -K
> 
> On Apr 1, 2010, at 12:14 PM, Kathryn Huxtable wrote:
> 
> > I know the docs say that wagon-scm has only been
> tested with CVS and Subversion, and I've run it with
> Subversion successfully.
> > 
> > Is anyone working on getting it to work with Git, or
> does it already?
> > 
> > I created a very simply project with a README and a
> pom.xml and nothing else. It's at
> > 
> >     http://github.com/khuxtable/test-project
> > 
> > It uses versions 1.3 of the gitexe and
> scm-manager-plexus extensions and version 1.0-beta-6 of the
> scm wagon.
> > 
> > What I would like to do is deploy my site docs (all
> generated by the site plugin) to the gh-pages branch of the
> git repository. I don't see any way in the Git SCM URL
> structure to specify a branch. If there was a way to do this
> it would be cool.
> > 
> > But at the moment, with the URL
> > 
> >     scm:git:ssh://g...@github.com/khuxtable/test-project.git
> > 
> > I get the following:
> > 
> > [INFO] [site:deploy {execution: default-cli}]
> > scm:git:ssh://github.com/khuxtable/test-project.git -
> Session: Opened  
> > Uploading: . to
> scm:git:ssh://github.com/khuxtable/test-project.git
> > 
> > [INFO] Executing: /bin/sh -c cd
> /Users/huxtable/Documents/workspace/test-project/.
> && git ls-files
> > [INFO] Working directory:
> /Users/huxtable/Documents/workspace/test-project/.
> > [INFO] Executing: /bin/sh -c cd
> /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp- &&
> git clone ssh://g...@github.com/khuxtable/test-project.git/.
> /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-/wagon-scm223596417.checkout
> > [INFO] Working directory:
> /var/folders/M+/M+95phY6GfOYTLYCJKW4Bk+++TI/-Tmp-
> > Transfer error: org.apache.maven.scm.ScmException:
> Unable to commit file. The git-clone command failed. ERROR:
> Repository not found.  Make sure you include the .git,
> e.g. g...@github.com:defunkt/ambition.git
> > fatal: The remote end hung up unexpectedly
> > 
> > scm:git:ssh://github.com/khuxtable/test-project.git -
> Session: Disconnecting  
> > scm:git:ssh://github.com/khuxtable/test-project.git -
> Session: Disconnected
> > 
> > I particularly like the "/." after the repository
> name. Funny.
> > 
> > The maven release plugin behaves fine with the same
> developerConnection as my site URL above.
> > 
> > Any ideas? I'm happy to help out with making this
> work, though I'm not a committer at this point.
> > 
> > -K
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

AW: mvn release:prepare using git, fatal: pom.xml is outside repository

[Mark Struberg]

Can you post a tree of your project structure?

And from where in the project tree do you start the release?

txs,
strub

--- Ricky Clarkson  schrieb am Di, 30.3.2010:

> Von: Ricky Clarkson 
> Betreff: mvn release:prepare using git, fatal: pom.xml is outside repository
> An: "Maven Users List" 
> Datum: Dienstag, 30. März, 2010 14:21 Uhr
> Hi,
> 
> I'm trying to tag a release using mvn release:prepare, and
> I see that
> a child module's pom.xml cannot be committed:
> 
> The git-add command failed.
> Command output:
> fatal: 'C:\Documents and
> Settings\Ricky\SkyTab\skytab\pom.xml' is
> outside repository
> 
> Any suggestions?
> 
> Thanks,
> Ricky.
> 
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1928 706373
> Skype: ricky_clarkson
> Google Talk: ricky.clark...@gmail.com
> Google Wave: ricky.clark...@googlewave.com
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

Re: Does wagon-scm work with maven-scm-provider-gitexe?

[Mark Struberg]

Hi folks!

GitListCommand.java is available in maven-scm-providers-gitexe since the very 
beginning (aka maven-scm-1.1) [1].

So maybe the issue is a different one?

LieGrue,
strub


[1] 
https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.1/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/list/


--- Brett Porter  schrieb am Di, 30.3.2010:

> Von: Brett Porter 
> Betreff: Re: Does wagon-scm work with maven-scm-provider-gitexe?
> An: "Maven Users List" 
> Datum: Dienstag, 30. März, 2010 07:33 Uhr
> 
> On 30/03/2010, at 4:12 PM, Kathryn Huxtable wrote:
> 
> > Okay, I see, looking at the source for
> maven-scm-provider-gitexe that "list" isn't implemented. It
> is apparently used by the wagen-scm extension. I've verified
> that the wagon-scm does work with my subversion repo.
> > 
> > So git just isn't as mature at this point.
> > 
> > Is anyone actively developing wagon-scm?
> > 
> > Why aren't the wagons compatible with version 1.3 of
> the scm code. I couldn't use anything later than 1.1 if I
> wanted the wagon-scm to work.
> > 
> > Inquiring minds want to know...
> 
> I responded on wagon-users@ where you posted:
> 
> It looks like the project is using an older version of
> [plexus-utils] than is needed (at least 1.5.6). You should
> add the newer version to you extensions also. Re-ordering
> the extensions so that SCM is listed first may also help.
> 
> > 
> > -K
> > 
> > On Mar 28, 2010, at 9:29 PM, Kathryn Huxtable wrote:
> > 
> >> And if so, what versions?
> >> 
> >> I'm working on a plugin, so I'm including a bunch
> of plexus and other stuff. Is that important?
> >> 
> >> I have the following in my POM:
> >> 
> >> 
> >> 
> >>   org.apache.maven.wagon
> >>   wagon-scm
> >>   1.0-beta-6
> >> 
> >> 
> >>   org.apache.maven.scm
> >>   maven-scm-manager-plexus
> >>   1.3
> >> 
> >> 
> >>   org.apache.maven.scm
> >>   maven-scm-provider-gitexe
> >>   1.3
> >> 
> >> 
> >> 
> >> And:
> >> 
> >> 
> >> ...
> >> 
> >>   gh-pages
> >>   scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
> >> 
> >> 
> >> 
> >> I'm using version 2.1 of the site plugin. When I
> run "mvn site:deploy" I get:
> >> 
> >> [INFO] [site:deploy {execution: default-cli}]
> >> scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
> - Session: Opened  
> >> Uploading: . to 
> >> scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
> >> 
> >> scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
> - Session: Disconnecting  
> >> scm:git:g...@github.com:khuxtable/imagegenerator-maven-plugin.git
> - Session: Disconnected
> >> [FATAL ERROR]
> org.apache.maven.plugins.site.SiteDeployMojo#execute()
> caused a linkage error (java.lang.NoSuchMethodError) and may
> be out-of-date. Check the realms:
> >> [FATAL ERROR] Plugin realm =
> app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
> >> urls[0] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
> >> urls[1] =
> file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
> >> urls[2] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
> >> urls[3] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
> >> urls[4] =
> file:/Users/huxtable/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
> >> urls[5] =
> file:/Users/huxtable/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
> >> urls[6] =
> file:/Users/huxtable/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
> >> urls[7] =
> file:/Users/huxtable/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
> >> urls[8] =
> file:/Users/huxtable/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> >> urls[9] =
> file:/Users/huxtable/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> >> urls[10] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
> >> urls[11] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
> >> urls[12] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
> >> urls[13] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
> >> urls[14] =
> file:/Users/huxtable/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.1.2/doxia-site-renderer-1.1.2.jar
> >> urls[15] =
> file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
> >> urls[16] =
> file:/Users/huxtable/.m2/repository/org/codehaus/plexus/plexus-velocity/1.1.8/plexus-velocity-1.1.8.jar
> >> urls[17]

[ANN]openjpa-maven-plugin-1.1 released

[Mark Struberg]

Hi!

I'm happy to announce the release of the openjpa-maven-plugin-1.1 [1].

This version has been tested with OpenJPA-1.1, 1.2 and various 2.0.0 versions. 
The following issues have been fixed [2] since 1.0:

Bug

* [MOPENJPA-11] - Empty properties cause exception to be thrown when 
running openjpa:schema
* [MOPENJPA-12] - property setting ignored with openjpa:schema
* [MOPENJPA-13] - Class enhancing fails with custom persistence.xml
* [MOPENJPA-17] - Dependencies with scope test must be on enhancement 
classpath as well

Improvement

* [MOPENJPA-7] - upgrade documentation to reflect latest changes
* [MOPENJPA-16] - the openjpa-plugin mojos shall not get executed for 
projets with packaging type 'pom'
* [MOPENJPA-18] - add a 'skip' flag to omit execution of all openjpa mojos
* [MOPENJPA-19] - make openjpa-dependency optional
* [MOPENJPA-20] - Add named parameters to allow adding of 
ConnectionDriverName and ConnectionProperties
* [MOPENJPA-29] - upgrade to mojo-parent-23

New Feature

* [MOPENJPA-2] - add a config property to specify a specific 
persistence.xml location and name.

Documentation can be found here: [3].


txs and LieGrue,
strub

[1] http://repository.codehaus.org/org/codehaus/mojo/openjpa-maven-plugin/1.1/
[2] 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11931&version=15975
[3] http://mojo.codehaus.org/openjpa-maven-plugin/


__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

Re: AW: release plugin doesnt update parent pom

[Mark Struberg]

hi!

since I have not much time left now, I can only ask a quick hint:

What about moving the parent pom.xml (containing the ) 
down into your build directory and create an own 'build' pom.xml (containing 
the ) in the parent directory? This definitely works and is used e.g. 
by JBoss folks for their 'version-matrix' (see e.g. the weld build).

LieGrue,
strub

--- is_maximum  schrieb am Sa, 26.12.2009:

> Von: is_maximum 
> Betreff: Re: AW: release plugin doesnt update parent pom
> An: users@maven.apache.org
> Datum: Samstag, 26. Dezember 2009, 13:11
> 
> Thanks.
> Actually NO. it create the release version with the same
> parent SNAPSHOT
> version. This only happens if you have a parent pom and not
> dependency. To
> clarify let me tell you that we have a core-parent project
> which is contains
> only a pom.xml with common dependencies for all projects to
> be inherited. in
> each project if I have a SNAPSHOT version, the release goal
> will fail but in
> our case that core-parent is SNAPSHOT it only asks to
> update and I reply
> 'yes' but no change is applied.
> 
> Yes you're right that the plugin cannot access the scm path
> of the
> core-parent so I supposed that it can read from the remote
> repository and
> find (suggest) the last release version.
> 
> This is useful because we use TeamCity to automatically
> build and generate
> release version say weekly. Because this process runs
> automatically we
> cannot change the SNAPSHOT version manually. 
> 
> Another problem is that the first question the
> release:prepare asks :
> 
> There are still some remaining snapshot dependencies.: Do
> you want to
> resolve them now? (yes/no) no:
> 
> and you see the default is NO and if you answer no the
> process will fail, so
> I think this should be defaulted to YES because when I am
> going to create a
> release (especially in multi-module projects) I need to
> resolve all the
> snapshot version.
> Why I need it to be dafaulted to yes? because we can ask
> our TeamCity
> software to create release version with -B option so
> everything will go
> right
> 
> Do you agree me?
> 
> Thanks for your reply
> 
> 
> 
> 
> 
> struberg wrote:
> > 
> > I think this is a minor bug.
> > 
> > let's sum up the facts:
> > 
> > a.) if you start the mvn release:prepare in a certain
> directory, maven
> > will _not_ automatically step out of this directory.
> > 
> > b.) If the parent pom is outside of your 
> url location, then it
> > cannot get updated.
> > 
> > I think the correct behaviour would be to fail with a
> 'cannot release with
> > a SNAPSHOT dependency' exception in your case. 
> > 
> > You can easily work around this issue if you manually
> release the parent
> > pom first.
> > 
> > LieGrue,
> > strub
> >  
> > --- is_maximum 
> schrieb am Sa, 26.12.2009:
> > 
> >> Von: is_maximum 
> >> Betreff: release plugin doesnt update parent pom
> >> An: users@maven.apache.org
> >> Datum: Samstag, 26. Dezember 2009, 12:10
> >> 
> >> Hi
> >> Consider a multi-module project with a root
> pom.xml and
> >> this root pom has
> >> another parent pom.xml which is considered as
> separated
> >> project 
> >> 
> >> 
> >>    
> >> com.foo.core
> >>    
> >> core-parent
> >>    
> >> 0.0.2-SNAPSHOT
> >> 
> >> 
> >> when executing release:prepare however the command
> asks to
> >> update this
> >> parent dependency to 0.0.3-SNAPSHOT but in action
> no
> >> changes I can see and
> >> this parent pom version remains intact
> >> 
> >> is this a bug or I missed something here?
> >> 
> >> 
> >> -
> >> --
> >> Regards
> >> 
> >> Mohammad Norouzi
> >> 
> >> Help each other to reach the future faster
> >> 
> >> http://pixelshot.wordpress.com Pixelshot
> Photoblog 
> >> 
> >> http://brainable.blogspot.com Brainable
> Blog 
> >> 
> >> 
> >> -- 
> >> View this message in context:
> >> http://old.nabble.com/release-plugin-doesnt-update-parent-pom-tp26926510p26926510.html
> >> Sent from the Maven - Users mailing list archive
> at
> >> Nabble.com.
> >> 
> >> 
> >>
> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> >> 
> > 
> > __
> > Do You Yahoo!?
> > Sie sind Spam leid? Yahoo! Mail verfügt über einen
> herausragenden Schutz
> > gegen Massenmails. 
> > http://mail.yahoo.com
> > 
> >
> -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > 
> > 
> 
> 
> -
> --
> Regards
> 
> Mohammad Norouzi
> 
> Help each other to reach the future faster
> 
> http://pixelshot.wordpress.com Pixelshot Photoblog 
> 
> http://brainable.blogspot.com Brainable Blog 
> 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/release-plugin-doesnt-update-parent-pom-tp26926510p26926790.html
> Sent from the 

AW: release plugin doesnt update parent pom

[Mark Struberg]

I think this is a minor bug.

let's sum up the facts:

a.) if you start the mvn release:prepare in a certain directory, maven will 
_not_ automatically step out of this directory.

b.) If the parent pom is outside of your  url location, then it cannot get 
updated.

I think the correct behaviour would be to fail with a 'cannot release with a 
SNAPSHOT dependency' exception in your case. 

You can easily work around this issue if you manually release the parent pom 
first.

LieGrue,
strub
 
--- is_maximum  schrieb am Sa, 26.12.2009:

> Von: is_maximum 
> Betreff: release plugin doesnt update parent pom
> An: users@maven.apache.org
> Datum: Samstag, 26. Dezember 2009, 12:10
> 
> Hi
> Consider a multi-module project with a root pom.xml and
> this root pom has
> another parent pom.xml which is considered as separated
> project 
> 
> 
>    
> com.foo.core
>    
> core-parent
>    
> 0.0.2-SNAPSHOT
> 
> 
> when executing release:prepare however the command asks to
> update this
> parent dependency to 0.0.3-SNAPSHOT but in action no
> changes I can see and
> this parent pom version remains intact
> 
> is this a bug or I missed something here?
> 
> 
> -
> --
> Regards
> 
> Mohammad Norouzi
> 
> Help each other to reach the future faster
> 
> http://pixelshot.wordpress.com Pixelshot Photoblog 
> 
> http://brainable.blogspot.com Brainable Blog 
> 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/release-plugin-doesnt-update-parent-pom-tp26926510p26926510.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

Re: AW: No such provider: 'git'

[Mark Struberg]

hi!

You catched a very old finesse of reporting plugin configuration (in fact, lots 
of Jira issues have been opened for that very topic).

Please read 
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
for an example how it should work.

LieGrue,
strub

--- jfinkels  schrieb am So, 20.12.2009:

> Von: jfinkels 
> Betreff: Re: AW: No such provider: 'git'
> An: users@maven.apache.org
> Datum: Sonntag, 20. Dezember 2009, 20:49
> 
> Oh, it looks like this issue was fixed in
> maven-changelog-plugin version 2.2:
> 
> http://jira.codehaus.org/browse/MCHANGELOG-92
> 
> But version 2.2 is not in the repository yet...
> -- 
> View this message in context: 
> http://old.nabble.com/No-such-provider%3A-%27git%27-tp26859089p26866688.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

AW: No such provider: 'git'

[Mark Struberg]

Hi!

You need to add the dependency of the gitexe provider to the 
maven-changelog-plugin and not to the build.

Maven is basically a container like you know from a ServletEngine: it separates 
classloaders of different plugins from each other - and the  for compile 
and test are 2 others of that kind.

Which means: if you add a dependency (of compile) to your  
section, this will not be available on the classpath of your plugin. Instead, 
as mentioned above, you have to add the dependency to the plugin itself (you 
might need a  section in your case).

LieGrue,
strub

--- jfinkels  schrieb am Sa, 19.12.2009:

> Von: jfinkels 
> Betreff: No such provider: 'git'
> An: users@maven.apache.org
> Datum: Samstag, 19. Dezember 2009, 23:16
> 
> I am unable to generate a changelog report using a git
> provider.
> 
> I have set up my POM with the following sections:
> ...
>   
>     
>       
>        
> org.apache.maven.plugins
>        
> maven-scm-plugin
>         
>          
> connection
>         
>         
>           
>            
> org.apache.maven.scm
>            
> maven-scm-provider-gitexe
>            
> 1.2
>           
>         
>             
>     
>   
> 
>   
>     
>       
>        
> org.apache.maven.plugins
>        
> maven-changelog-plugin
>       
>     
>   
> 
>   
>    
> scm:git:git://github.com/jfinkels/jmona.git
>     http://github.com/jfinkels/jmona
>   
> ...
> 
> But I get the following error when trying to generate a
> report with "mvn
> site":
> 
>   "Embedded error: Error rendering Maven report:
> Cannot run changelog
> command : 
>    No such provider: 'git'."
> 
> There is a thread from June 2008 related to this topic
> here:
> http://www.mail-archive.com/scm-us...@maven.apache.org/msg00055.html
> 
> How can I get a changelog report using git?
> -- 
> View this message in context: 
> http://old.nabble.com/No-such-provider%3A-%27git%27-tp26859089p26859089.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

AW: pom.xml : element

[Mark Struberg]

the  element in the pom is used for every SCM action in maven, e.g. if you 
do a mvn release:prepare / mvn release:perform and stuff.

Since Hudson and other CI environments often do not rely on the build system 
for updating the project, they have the ability to do this their self (otoh, 
some CI systems do use maven-scm internally, but get the scm URL parameter from 
the UI rather than the pom.

LieGrue,
strub

--- Rémy  schrieb am Mo, 14.12.2009:

> Von: Rémy 
> Betreff: pom.xml :  element
> An: users@maven.apache.org
> Datum: Montag, 14. Dezember 2009, 10:41
> 
> Hello,
> 
> What is the purpose of the  element defined in
> the pom.xml. I can't
> understand its usefulness.
> In Hudson, the link to the SCM is configured in the job.
> When I make a
> release (maven-release-plugin), I feel that the plugin is
> based on
> information contained in the workspace.
> 
> http://maven.apache.org/pom.html#SCM http://maven.apache.org/pom.html#SCM 
> 
> Thank you.
> 
> Remy
> 
> 
> -- 
> View this message in context: 
> http://old.nabble.com/pom.xml-%3A-%3Cscm%3E-element-tp26775153p26775153.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen 
Massenmails. 
http://mail.yahoo.com

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

AW: Problem with maven-release-plugin

[Mark Struberg]

Peter,

use the  section in the parent pom to pin down the 
versions of the single child modules.

LieGrue,
strub

--- Peter Niederwieser  schrieb am Do, 19.11.2009:

> Von: Peter Niederwieser 
> Betreff: Problem with maven-release-plugin
> An: users@maven.apache.org
> Datum: Donnerstag, 19. November 2009, 11:46
> 
> In my multi-module project, I have a Maven plugin A and a
> module B that uses
> version ${project.version} of A (all modules have the same
> version number).
> release:prepare changes version A from 0.3-SNAPSHOT to 0.3,
> but then fails
> while processing B because it cannot find version 0.3 of A.
> Any ideas how to
> solve this problem?
> 
> Cheers,
> Peter
> -- 
> View this message in context: 
> http://old.nabble.com/Problem-with-maven-release-plugin-tp26421272p26421272.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> 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

AW: NAR plugin

[Mark Struberg]

fetching alone is not enough.
You have to do a 

git pull

instead. This is a combined git fetch + git merge.

LieGrue,
strub



- Ursprüngliche Mail 
> Von: Damon Jacobsen 
> An: Maven Users List 
> Gesendet: Mittwoch, den 28. Oktober 2009, 17:16:31 Uhr
> Betreff: RE: NAR plugin
> 
> Mark,
> 
> I am by no means proficient with git yet, but here is what I did. 
> Yesterday, 
> using msysgit, I 'cloned' http://github.com/duns/maven-nar-plugin.git and 
> http://github.com/duns/cpptasks-parallel.git. Today I 'fetched' from origin. 
> I 
> think this syncs me with any changes made on the head. I have 'mvn install'ed 
> both of them this morning.
> 
> Damon
> 
> -Original Message-
> From: Donszelmann Mark [mailto:mark.donszelm...@gmail.com] 
> Sent: Wednesday, October 28, 2009 8:49 AM
> To: Maven Users List
> Subject: Re: NAR plugin
> 
> Hi Damon,
> 
> are you sure you are running the latest NAR from github ?
> 
> Regards
> Mark
> 
> On Oct 28, 2009, at 4:23 PM, Damon Jacobsen wrote:
> 
> > Mark,
> >
> > Thanks for the info. The results confirm that the include files are  
> > not being added. I think it is due to some odd behavior with spaces  
> > in files path. Boy I wish windows could get that correct. Here is my  
> > output.
> >
> > [DEBUG] bcc32  -c -X -x -tWM -Od -DWindows -DWIN32 '-I"H:\workspace 
> > \ImagenomicPortraturePluginDLL\target\nar\javah-include"' '-I"C: 
> > \Program Files\Java\jdk1.6.0_16\include"' '-I"C:\Program Files\Java 
> > \jdk1.6.0_16\include\win32"' -IH:\workspace 
> > \ImagenomicPortraturePluginDLL\src\main\include -IH:\workspace 
> > \ImagenomicPortraturePluginDLL\target\swig\include -w H:\workspace 
> > \ImagenomicPortraturePluginDLL\src\main\c++ 
> > \com_lifetouch_ImagenomicPortraitureBufferedImageOp.cpp
> > [DEBUG] Execute:Java13CommandLauncher: Executing 'bcc32' with  
> > arguments:
> > ''
> > '-c'
> > '-X'
> > '-x'
> > '-tWM'
> > '-Od'
> > '-DWindows'
> > '-DWIN32'
> > '-I"H:\workspace\ImagenomicPortraturePluginDLL\target\nar\javah- 
> > include"'
> > '-I"C:\Program Files\Java\jdk1.6.0_16\include"'
> > '-I"C:\Program Files\Java\jdk1.6.0_16\include\win32"'
> > '-IH:\workspace\ImagenomicPortraturePluginDLL\src\main\include'
> > '-IH:\workspace\ImagenomicPortraturePluginDLL\target\swig\include'
> > '-w'
> > 'H:\workspace\ImagenomicPortraturePluginDLL\src\main\c++ 
> > \com_lifetouch_Imagenomi
> > cPortraitureBufferedImageOp.cpp'
> >
> > The ' characters around the executable and arguments are
> > not part of the command.
> > [DEBUG] Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
> > [DEBUG] Error E2194: Could not find file 'Files\Java 
> > \jdk1.6.0_16\include.cpp'
> > [DEBUG] Error E2194: Could not find file 'Files\Java 
> > \jdk1.6.0_16\include\win32.c
> > pp'
> >
> > Cleaning up the command line to remove the ' character and issuing  
> > it at the command line does not have this problem.
> >
> > Damon
> >
> > -Original Message-
> > From: Donszelmann Mark [mailto:mark.donszelm...@gmail.com]
> > Sent: Wednesday, October 28, 2009 8:03 AM
> > To: Maven Users List
> > Subject: Re: NAR plugin
> >
> > Hi
> >
> > if you run the NAR plugin with -X it will show that, and a lot of
> > other info, so be prepared.
> >
> > You may just want to use the free Visual Studio Express (version 2008)
> > to compile and link with.
> >
> > Regards
> > Mark Donszelmann
> >
> >
> > On Oct 28, 2009, at 3:59 PM, Damon Jacobsen wrote:
> >
> >> Martin,
> >>
> >> I considered using cygwin, but I read that code compiled with it
> >> needs cygwin installed on the target machine to run. I was hoping
> >> just to just use the free borland compiler for a quick solution. I
> >> am thinking if there was a way to see the command given to compile,
> >> I could fix it. Is there any way to have that information logged or
> >> pumped to stdout?
> >>
> >> Damon
> >>
> >> -Original Message-
> >> From: Martin Gainty [mailto:mgai...@hotmail.com]
> >> Sent: Tuesday, October 27, 2009 5:48 PM
> >> To: users@maven.apache.org
> >> Subject: RE: NAR plugin
> >>
> >>
> >> Damon-
> >>
> >> some company in texas purchased the borland compiler and i dont know
> >> what happened afterwards
> >> i had the same problem with Borland Compiler and punted to
> >> cygwin...download the full devel package.. gcc is the compiler..ld
> >> is the linker..ar is the library manager
> >> http://www.cygwin.com
> >>
> >> Martin Gainty
> >> __
> >> Verzicht und Vertraulichkeitanmerkung/Note de déni et de
> >> confidentialité
> >>
> >> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> >> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
> >> unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig.
> >> Diese Nachricht dient lediglich dem Austausch von Informationen und
> >> entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten
> >> Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer 

Re: Running Jar file created by Maven

[Mark Struberg]

I'd use the maven-shade-plugin because a) it's a maven-core-plugin and as such 
it's pretty well maintained b) it can also 'shade' concurring jars into 
different packages if there are some dependency problems.

LieGrue,
strub

--- On Tue, 10/13/09, Albert Kurucz  wrote:

> From: Albert Kurucz 
> Subject: Re: Running Jar file created by Maven
> To: "Maven Users List" 
> Date: Tuesday, October 13, 2009, 5:40 PM
> Always nice to have choices.
> Now, which one is better, the onejar-maven-plugin or
> fatjar?
> 
> On Tue, Oct 13, 2009 at 7:15 AM, Stevo Slavić 
> wrote:
> > http://code.google.com/p/onejar-maven-plugin/
> >
> > http://anydoby.com/fatjar/
> >
> > Regards,
> > Stevo.
> >
> > On Tue, Oct 13, 2009 at 2:03 PM, Marcin Kwapisz 
> > wrote:
> >
> >> > but if I try to build it from the command
> prompt using mvn
> >> > install,
> >> > it build the whole staff, but when I try to
> run the jar file, it just
> >> > fails
> >> > becuase it cannot find the library files
> (dependencies), looks like
> >> > maven
> >> > doesn't add those files, although it
> downloads them...
> >>
> >> [Marcin Kwapisz]
> >> Maven does not pack jar into jar. You can use
> assembly plugin to do that
> >> (as Eric Lewis wrote), but you can also use
> dependency plugin to copy
> >> dependencies (needed libraries) to you Target
> directory (or directory where
> >> your main jar is located).
> >>
> >> Regards
> >> Marcin Kwapisz
> >>
> >>
> >>
> -
> >> 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
> 
> 




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

Re: AW: AW: Running Jar file created by Maven

[Mark Struberg]

If it's really a standalone app, you can also use the maven-shade-plugin [1] 
for creating an 'uber-jar' which contains all the dependencies.

LieGrue,
strub

[1] http://maven.apache.org/plugins/maven-shade-plugin/

--- On Tue, 10/13/09, Entner Harald  wrote:

> From: Entner Harald 
> Subject: AW: AW: Running Jar file created by Maven
> To: "Maven Users List" 
> Date: Tuesday, October 13, 2009, 11:50 AM
> How do you run the jar file? (outside
> netbeans). 
> 
> with java -jar  ? 
> 
> If you do so, the jar files need to be included in the
> resulting jar file, or you have to add it to the classpath,
> via -cp ...
> 
> -Ursprüngliche Nachricht-
> Von: jamborta [mailto:jambo...@gmail.com]
> 
> Gesendet: Dienstag, 13. Oktober 2009 11:38
> An: users@maven.apache.org
> Betreff: Re: AW: Running Jar file created by Maven
> 
> 
> it's a pure java project. and it runs OK inside netbeans. I
> get a
> NoClassDefFoundError if try to run it from the command
> line:
> 
> Exception in thread "main" java.lang.NoClassDefFoundError:
> cern/colt/function/In
> tObjectProcedure
>         at
> com.main.App.main(App.java:36)
> Caused by: java.lang.ClassNotFoundException:
> cern.colt.function.IntObjectProcedu
> re
>         at
> java.net.URLClassLoader$1.run(Unknown Source)
>         at
> java.security.AccessController.doPrivileged(Native Method)
>         at
> java.net.URLClassLoader.findClass(Unknown Source)
>         at
> java.lang.ClassLoader.loadClass(Unknown Source)
>         at
> sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
>         at
> java.lang.ClassLoader.loadClass(Unknown Source)
>         at
> java.lang.ClassLoader.loadClassInternal(Unknown Source)
>         ... 1 more
> 
> 
> 
> What kind of project are you talking about? Is it a pure
> Java project or
> does it run inside glassfish (for example)? What class
> files are missing?
> How does the stacktrace look like? 
> 
> Try to add the missing artifacts to the pom.
> 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Running-Jar-file-created-by-Maven-tp25869690p25869863.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> 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
> 
> 




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

Re: How to Invoke Maven inside Java Program

[Mark Struberg]

have you looked at the maven-embedder [1]?

LieGrue,
strub

[1] http://maven.apache.org/guides/mini/guide-embedding-m2.html



--- On Mon, 10/12/09, harishsyndrome  wrote:

> From: harishsyndrome 
> Subject: How to Invoke Maven inside Java Program
> To: users@maven.apache.org
> Date: Monday, October 12, 2009, 1:31 PM
> 
> Is there any launcher or API kind of thing to invoke maven
> inside a java
> program.
> 
> In Ant
> 
> I can invoke ant task using Ant Launcher
> 
> Launcher.main(String[]);
> 
> Is there any thing similar to that for maven.
> 
> I desperately need that.
> 
> Thankyou.
> -- 
> View this message in context: 
> http://www.nabble.com/How-to-Invoke-Maven-inside-Java-Program-tp25854205p25854205.html
> Sent from the Maven - Users mailing list archive at
> Nabble.com.
> 
> 
> -
> 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: maven-ant-run plugin 1.3 error java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.close

[Mark Struberg]

Hmm maybe it's as simple as that: the maven-antrun-plugin only has the core 
dependencies on board. If your ant scripts make use of additional functions, 
you have to add those jars as dependencies.
E.g.:

> 
>  maven-antrun-plugin
>  ... 
>  
>   
>ant
>ant-nodeps
>1.6.5
>   
>  
>  

LieGrue,
strub

--- On Thu, 10/8/09, Jörg Schaible  wrote:

> From: Jörg Schaible 
> Subject: Re: maven-ant-run plugin 1.3 error java.lang.NoSuchMethodError: 
> org.apache.tools.ant.util.FileUtils.close
> To: users@maven.apache.org
> Date: Thursday, October 8, 2009, 6:35 PM
> Hi Doug,
> 
> Doug Daniels wrote:
> 
> > I'm building a maven project that uses the
> maven-ant-run plugin and I'm
> > getting an error about a missing method from Ant.
> 
> Does this happen in a multi-project build or when you try
> to build the
> project directly? Which other plugins did run before the
> install phase?
> 
> - Jörg
> 
> 
> 
> -
> 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: Maven and ClearCase UCM

[Mark Struberg]

you might look at

http://maven.apache.org/guides/mini/guide-releasing.html

to get a first impression.


LieGrue,
strub

--- On Thu, 9/10/09, Andrew Close  wrote:

> From: Andrew Close 
> Subject: Re: Maven and ClearCase UCM
> To: "Maven Users List" 
> Date: Thursday, September 10, 2009, 5:55 PM
> On Thu, Sep 10, 2009 at 10:35 AM,
> Mark Struberg
> wrote:
> > do you guys use mvn release:prepare and mvn
> release:perform?
> > This should increment the versions automatically!
> >
> > Please also read through the section covering
>  in the 'definitive maven
> guide'.
> >
> > LieGrue,
> > strub
> 
> not yet.  i've been begging our SCM team to learn a
> little bit about
> Maven so that we can start making better use of plugins.
> 
> 
> -- 
> Andrew Close
> 
> -
> 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: Maven and ClearCase UCM

[Mark Struberg]

do you guys use mvn release:prepare and mvn release:perform?
This should increment the versions automatically!

Please also read through the section covering  in the 
'definitive maven guide'.

LieGrue,
strub

--- On Thu, 9/10/09, Andrew Close  wrote:

> From: Andrew Close 
> Subject: Re: Maven and ClearCase UCM
> To: "Maven Users List" 
> Date: Thursday, September 10, 2009, 4:29 PM
> On Thu, Sep 10, 2009 at 8:59 AM,
> Bruce Albrecht
> wrote:
> > Is anyone using Maven with ClearCase UCM with
> developers using children
> > streams with dynamic views?  If so, how do you manage
> bumping the POM
> > versions?  Do you rely on the developers doing it
> manually, or use an
> > automatic process?  If we automate it, it looks like
> we potentially need to
> > strip the -SNAPSHOT in the POMs' version before
> creating a baseline, create
> > a baseline, update the POMs to new -SNAPSHOT versions,
> and then create a
> > second baseline so that the developers can rebase
> against it. Is there a
> > better way that we're overlooking?  Thanks!
> 
> hi Bruce,
> 
> we recently converted our SCM from MS VSS to CC UCM and our
> build
> system from a very poor ANT implementation (not that ANT is
> poor, our
> implementation was) to Maven.  we're still struggling
> with growing
> pains/conversion pains and have yet to automate
> versioning.  i'm
> hoping that others speak up cause we'd like some ideas as
> well. :)
> our setup/process is pretty poor at the moment mainly due
> to the
> amount of baggage our systems carry.
> we currently rely on the developers to set their versions
> to SNAPSHOT
> during development.  everything on the dev stream is
> SNAPSHOT.  when
> we move to Integration testing we create a new stream that
> everyone
> delivers to and the versions are set to hard
> versions.  everything is
> built and tested and if ok delivered to the Prod stream by
> SCM.
> i can give you more details, but i'm hoping others step up
> with better
> solutions cause i'll be the first to tell you ours isn't
> the way to
> go. :)
> 
> -- 
> Andrew Close
> 
> -
> 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: Project and external file Deployment?

[Mark Struberg]

what about using an EAR?


LieGrue,
strub



- Original Message 
> From: Jan Wedel 
> To: users@maven.apache.org
> Sent: Friday, August 14, 2009 11:26:03 AM
> Subject: Project and external file Deployment?
> 
> Hi,
> 
> 
> 
> I was just wondering how I can configure Maven to deploy a whole
> project, e.g. a web application that needs other war files to also be
> deployed on the server as well as probable configuration files. 
> 
> 
> 
> Is it possible to copy other projects jar/war files together with the
> projects war into a web container e.g.? Image I have several web
> applications that interact with each other but which are not contained
> in a single war file. I could use maven to deploy each file separately.
> But maybe there are 3rd party war files which I like to deploy together
> with my files. Can I somehow specify files that belong to the project
> that I like to be deployed?
> 
> 
> 
> Thanks,
> 
> 
> 
> Jan



  

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

Re: SCM plugin password encryption

[Mark Struberg]

> can you not put your password in a property defined in your
> ~/.m2/settings.xml file and then reference that property in your scm
> config section?
Writing passwords into poms is surely always a dirty hack and using the private 
settings.xml is a good point indeed.

But on a CI server, the CI user usually is accessible by a lot of people.
Storing private credentials imho simply doesn't work in this case.

Otoh, for shadow password functionality, I fear this won't work since there is 
no way to restore the original password for sending it to the SCM system.

Imho the best way would be to create an own user for the CI system in the SCM 
which only has readonly access.

LieGrue,
strub



- Original Message 
> From: Stephen Connolly 
> To: Maven Users List 
> Sent: Friday, August 14, 2009 10:10:32 AM
> Subject: Re: SCM plugin password encryption
> 
> can you not put your password in a property defined in your
> ~/.m2/settings.xml file and then reference that property in your scm
> config section?
> 
> that way you can change the permissions on your ~/.m2/settings.xml
> file to make it only readable by yourself (unless you are using
> FAT/FAT32 as your filesystem eek!)
> 
> -Stephen
> 
> 2009/8/13 KURT TOMETICH :
> >
> > I feel like I must be missing something because I have yet found a way to 
> encrypt my SCM password in my Maven POM.  I am using the maven release plugin 
> and need to use some credentials on the CI server, but I don't want to store 
> the 
> password in clear text.  Is there a way to encrypt the password and reference 
> it 
> in the Maven SCM plugin?
> >
> > I've tried using the Maven encryption guide 
> (http://maven.apache.org/guides/mini/guide-encryption.html) which works well 
> for 
> encrypting Maven repository credentials.  The problem is that you can't (from 
> what I've seen) reference the id for a server in the Maven SCM plugin.  
> Here's 
> an example of what I'd like to see in the POM:
> >
> > 
> >   org.apache.maven.plugins
> >   maven-scm-plugin
> >   
> >kurt.tometich
> >{encrypted password here}
> >   
> > 
> >
> >
> > Any ideas of how to do this would be welcome.  Thanks in advance.
> >
> > Kurt
> >
> >
> >
> 
> -
> 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: SCM plugin password encryption

[Mark Struberg]

please create a jira!

I'll try to go over a few scm issues this weekend, maybe I have time for this 
too.

LieGrue,
strub



- Original Message 
> From: Andrei Solntsev 
> To: Maven Users List 
> Sent: Friday, August 14, 2009 9:23:28 AM
> Subject: RE: SCM plugin password encryption
> 
> We just need to add this feature to maven-scm-plugin.
> 
> We could use maven-sql-plugin as an example, it can read encrypted DB
> password in the same manner as repository credentials.
> 
> Andrei Solntsev,
> Software Developer,
> HireRight Estonia
> 
> 
> 
> -Original Message-
> From: KURT TOMETICH [mailto:boomtow...@msn.com] 
> Sent: Thursday, August 13, 2009 7:07 PM
> To: users@maven.apache.org
> Subject: SCM plugin password encryption
> 
> 
> I feel like I must be missing something because I have yet found a way
> to encrypt my SCM password in my Maven POM.  I am using the maven
> release plugin and need to use some credentials on the CI server, but I
> don't want to store the password in clear text.  Is there a way to
> encrypt the password and reference it in the Maven SCM plugin?
> 
> I've tried using the Maven encryption guide
> (http://maven.apache.org/guides/mini/guide-encryption.html) which works
> well for encrypting Maven repository credentials.  The problem is that
> you can't (from what I've seen) reference the id for a server in the
> Maven SCM plugin.  Here's an example of what I'd like to see in the POM:
> 
> 
>   org.apache.maven.plugins
>   maven-scm-plugin
>   
> kurt.tometich
> {encrypted password here}
>   
> 
> 
> 
> Any ideas of how to do this would be welcome.  Thanks in advance.
> 
> Kurt
> 
> 
> 
> -
> 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: How do I turn off the maven-source-plugin altogether?

[Mark Struberg]

have you tried to set 'attached' to false in the configuration section? [1]

From a quick look at the sources, it should then at least skip attaching the 
archive to the repository.

But maybe we should introduce a 'skip' property like many other plugin have.

Since I remember a discussion with lots of pros and cons with Benjamin a long 
time ago, we should probably think about 'skipping' or 'disabling' plugins in a 
derived pom as a general lifecycle feature for maven-3?
But I'm maybe not really up to date on this topic.

LieGrue,
strub

[1]  http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html#attach

--- On Fri, 7/31/09, Benson Margulies  wrote:

> From: Benson Margulies 
> Subject: Re: How do I turn off the maven-source-plugin altogether?
> To: "Maven Users List" 
> Date: Friday, July 31, 2009, 4:36 AM
> The super-pom turns out to document:
> 
>  
>            
> true
>            
> org.apache.maven.plugins
>            
> maven-source-plugin
> 
>            
> 
>              
> 
>                
> attach-sources
>                
> 
>                
>   jar
>                
> 
>              
> 
>            
> 
>           
> 
> 
> Which is the source of his charming situation. I need to
> rebind it to
> a nonexistent phase, I guess.
> 
> 
> On Thu, Jul 30, 2009 at 10:09 PM, Wayne Fay
> wrote:
> >> The maven-source-plugin is running in my lifecycle
> even though I never
> >> mention it in a pom. Is there a way to chase it
> out?
> >
> > Is it mentioned in a parent or grandparent pom? Are
> you using a
> > profile that brings it in -- perhaps one that is
> activeByDefault? Did
> > you check mvn help:effective-pom?
> >
> > What command are you running that results in m-s-p
> being executed? It
> > is bound to some profiles that automatically come down
> with Maven, so
> > you might be running into one of those, perhaps.
> >
> > Wayne
> >
> >
> -
> > 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
> 
> 




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

Re: Can I use WAR Overlay before packaging?

[Mark Struberg]

Hi!

I assume you like to debug/test your project in your IDE without needing to 
package the whole project every time, right?

It's long ago that I used WAR overlay the last time, but did you try 
war:inplace? 
You have to be aware that war:inplace will pollute your src/main/webapp working 
directory, though!

LieGrue,
strub

--- On Sat, 7/25/09, Néstor Boscán  wrote:

> From: Néstor Boscán 
> Subject: Can I use WAR Overlay before packaging?
> To: users@maven.apache.org
> Date: Saturday, July 25, 2009, 4:56 AM
> Hi
> 
>  
> 
> Is there a way to use WAR Overlay before packaging?. I
> would like to access
> the overlaid JSP files from my project. Is this possible?
> 
>  
> 
> Regards,
> 
>  
> 
> Néstor Boscán
> 
> 




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

RE: [ANN] Maven 2.2.0 Released

[Mark Struberg]

If it still doesn't work yet, the mirror I've been using was

http://www.eu.apache.org/dist/maven/binaries/apache-maven-2.2.0-bin.tar.gz

LieGrue,
strub

--- Jason Chaffee  schrieb am Mi, 1.7.2009:

> Von: Jason Chaffee 
> Betreff: RE: [ANN] Maven 2.2.0 Released
> An: "Maven Users List" 
> Datum: Mittwoch, 1. Juli 2009, 1:35
> I tried all the mirror links that
> were provided on that page and none of them worked for me so
> I thought there might be something else going on.
> 
> I will try again later.  
> 
> Thanks.
> 
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de]
> 
> Sent: Tuesday, June 30, 2009 4:29 PM
> To: Maven Users List
> Subject: RE: [ANN] Maven 2.2.0 Released
> 
> 
> Works for me.
> 
> Sometimes it takes a bit for all mirrors to get synced.
> Please try it again in a a few hours.
> 
> LieGrue,
> strub
> 
> --- Jason Chaffee 
> schrieb am Mi, 1.7.2009:
> 
> > Von: Jason Chaffee 
> > Betreff: RE: [ANN] Maven 2.2.0 Released
> > An: "Maven Users List" ,
> "annou...@maven.apache.org"
> 
> > Datum: Mittwoch, 1. Juli 2009, 1:04
> > I have not been able to download this
> > release.  It seems the artifact(s) are not at the
> > specified URL. 
> > 
> > -Original Message-
> > From: John Casey [mailto:jdca...@apache.org]
> > 
> > Sent: Tuesday, June 30, 2009 3:21 PM
> > To: annou...@maven.apache.org;
> > Maven Users List
> > Subject: [ANN] Maven 2.2.0 Released
> > 
> > The Maven team is pleased to announce the release of
> the
> > Maven 2.2.0.
> > 
> > Maven is a software project management and
> comprehension
> > tool. It offers
> > users the ability to build project binaries, generate
> a
> > project website,
> > and more.
> > 
> > http://maven.apache.org/
> > 
> > 
> > Release Notes - Maven 2 - Version 2.2.0
> > 
> > ** Sub-task
> >      * [MNG-4144] - document escape
> > character for curly braces in
> > clear-text passwords for settings.xml password
> security
> >      * [MNG-4145] - switch to released
> > versions of plexus-sec-dispatcher
> > (and by ext. plexus-cipher) once they're available
> > 
> > ** Bug
> >      * [MNG-2258] - Wrong execution
> > order of plugins in same phase
> >      * [MNG-3401] - Plugin parameters
> > must be specified outside an
> > execution block when they are invoked from the
> command
> > line
> >      * [MNG-3553] - cannot resolve
> > dependency with scope import
> >      * [MNG-3776] - Namespace
> > misspelled in settings.xml
> >      * [MNG-4074] - cyclic reference
> > with 2.1.0-RC1 that doesn't occur
> > with 2.0.10
> >      * [MNG-4082] - Encryption is
> > triggered if passwords merely contain
> > curly braces
> >      * [MNG-4126] - [regression]
> > Properties defined in profiles.xml of
> > parent are not inherited during multimodule build
> >      * [MNG-4137] - NPE in
> > DefaultLIfecycleExecutor when run from within
> > Hudson builds
> >      * [MNG-4140] - Properties
> > incorrectly replaced in pom
> >      * [MNG-4146] - password security
> > doesn't work with custom password
> > providers
> >      * [MNG-4147] - very long passwords
> > cause LightweightHTTP wagon to
> > line-wrap the Base64-encoded Authorization header
> >      * [MNG-4165] - http session
> > cookies rejected with non-lightweight
> > http wagon (maybe with lightweight one too)
> >      * [MNG-4166] - Problem parsing
> > command-line options in release:perform
> >      * [MNG-4167] - version-expression
> > transformation interferes with
> > plugins like GPG
> >      * [MNG-4168] - String index out of
> > range: 43807
> >      * [MNG-4179] - [regression]
> > Artifact download hangs upon transfer
> > failure
> >      * [MNG-4184] - [regression]
> > maven2.1 fails with cyclic dependency
> > in case of extension/dependency for report-plugin to
> > reactor-project
> >      * [MNG-4207] - Plugins that use
> > ArtifactResolver with http
> > repositories AND depend on log4j run into
> > ExceptionInInitializerError
> >      * [MNG-4213] - preemptive auth in
> > non-lightweight http wagon causes
> > Unauthorized responses from some servers
> >      * [MNG-4219] - update plexus-utils
> > to avoid leaking processes in
> > CommandLineUtils.getSystemEnvars()
> > 
> > ** Improvement
> >      * [MNG-2979] - Cross mod

RE: [ANN] Maven 2.2.0 Released

[Mark Struberg]

Works for me.

Sometimes it takes a bit for all mirrors to get synced.
Please try it again in a a few hours.

LieGrue,
strub

--- Jason Chaffee  schrieb am Mi, 1.7.2009:

> Von: Jason Chaffee 
> Betreff: RE: [ANN] Maven 2.2.0 Released
> An: "Maven Users List" , "annou...@maven.apache.org" 
> 
> Datum: Mittwoch, 1. Juli 2009, 1:04
> I have not been able to download this
> release.  It seems the artifact(s) are not at the
> specified URL. 
> 
> -Original Message-
> From: John Casey [mailto:jdca...@apache.org]
> 
> Sent: Tuesday, June 30, 2009 3:21 PM
> To: annou...@maven.apache.org;
> Maven Users List
> Subject: [ANN] Maven 2.2.0 Released
> 
> The Maven team is pleased to announce the release of the
> Maven 2.2.0.
> 
> Maven is a software project management and comprehension
> tool. It offers
> users the ability to build project binaries, generate a
> project website,
> and more.
> 
> http://maven.apache.org/
> 
> 
> Release Notes - Maven 2 - Version 2.2.0
> 
> ** Sub-task
>      * [MNG-4144] - document escape
> character for curly braces in
> clear-text passwords for settings.xml password security
>      * [MNG-4145] - switch to released
> versions of plexus-sec-dispatcher
> (and by ext. plexus-cipher) once they're available
> 
> ** Bug
>      * [MNG-2258] - Wrong execution
> order of plugins in same phase
>      * [MNG-3401] - Plugin parameters
> must be specified outside an
> execution block when they are invoked from the command
> line
>      * [MNG-3553] - cannot resolve
> dependency with scope import
>      * [MNG-3776] - Namespace
> misspelled in settings.xml
>      * [MNG-4074] - cyclic reference
> with 2.1.0-RC1 that doesn't occur
> with 2.0.10
>      * [MNG-4082] - Encryption is
> triggered if passwords merely contain
> curly braces
>      * [MNG-4126] - [regression]
> Properties defined in profiles.xml of
> parent are not inherited during multimodule build
>      * [MNG-4137] - NPE in
> DefaultLIfecycleExecutor when run from within
> Hudson builds
>      * [MNG-4140] - Properties
> incorrectly replaced in pom
>      * [MNG-4146] - password security
> doesn't work with custom password
> providers
>      * [MNG-4147] - very long passwords
> cause LightweightHTTP wagon to
> line-wrap the Base64-encoded Authorization header
>      * [MNG-4165] - http session
> cookies rejected with non-lightweight
> http wagon (maybe with lightweight one too)
>      * [MNG-4166] - Problem parsing
> command-line options in release:perform
>      * [MNG-4167] - version-expression
> transformation interferes with
> plugins like GPG
>      * [MNG-4168] - String index out of
> range: 43807
>      * [MNG-4179] - [regression]
> Artifact download hangs upon transfer
> failure
>      * [MNG-4184] - [regression]
> maven2.1 fails with cyclic dependency
> in case of extension/dependency for report-plugin to
> reactor-project
>      * [MNG-4207] - Plugins that use
> ArtifactResolver with http
> repositories AND depend on log4j run into
> ExceptionInInitializerError
>      * [MNG-4213] - preemptive auth in
> non-lightweight http wagon causes
> Unauthorized responses from some servers
>      * [MNG-4219] - update plexus-utils
> to avoid leaking processes in
> CommandLineUtils.getSystemEnvars()
> 
> ** Improvement
>      * [MNG-2979] - Cross module
> dependencies for multi-module site
>      * [MNG-3203] - maven should
> execute compiler:compile and
> :test-compile in separate executions, to allow separate
> configuration
>      * [MNG-3834] - Improve error
> message when dependency with
> classifier is missing version
>      * [MNG-4210] - Remove log4j
> configuration warning
> 
> 
> ** Task
>      * [MNG-4143] - Update Java
> requirement to 1.5
>      * [MNG-4169] - Remove invocation
> of
> maven-plugin-plugin:updatePluginRegistry from default
> lifecycle bindings
> 
> 
> ** Wish
>      * [MNG-4139] - avoid the schema
> location in generated
> maven-metadata*.xml
> 
> 
> Enjoy,
> 
> -The Maven team
> 
> 
> -- 
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
> 
> -
> 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
> 
> 


   

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

AW: About unittest run three times

[Mark Struberg]

Old story, and as far as I remember (please correct me if I'm wrong) the reason 
is:

The site lifecycle and the default build lifecycle are isolated things.
So if you run mvn install, the 'test' phase will be invoked -> 1st run

Your site has a test reporting section? -> 2nd run

I assume you have cobertura or another code coverage tool enabled?
Because this runs all the tests in an instrumended form -> 3nd run

I'm not saying this situation is optimal though ;) This especially sucks while 
running releases, because prepare and perform will do all those steps a few 
times...

LieGrue,
strub


--- forum geng  schrieb am Mi, 20.5.2009:

> Von: forum geng 
> Betreff: About unittest run three times
> An: users@maven.apache.org
> Datum: Mittwoch, 20. Mai 2009, 8:30
> Dear all,
> 
>            While I set
> the nightly build command for continum by "clean
> install site-deploy", my unit tests all run for three
> times.
>            And while I
> changed to "clean install", the unit tests run for
> one time, and changed to "clean site-deploy", my unit tests
> run for two
> times.
> 
>           Are there any to explain
> the behind mechanism?
>           And my requirement is
> that to let all the unit tests run for only
> time, and I can also find the info from the deployed site,
> such as with
> PMD/FindBug related report.
> 
> Thanks.
> 
> Forest.
> 




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

AW: Automagically update scm tag

[Mark Struberg]

Hi Baptiste!

It isn't clear to me what you mean with 'update tag'.

Do you like to re-tag in the SCM?

LieGrue,
strub



- Ursprüngliche Mail 
> Von: Baptiste MATHUS 
> An: Maven Users List 
> Gesendet: Dienstag, den 5. Mai 2009, 09:34:51 Uhr
> Betreff: Re: Automagically update scm tag
> 
> Well, not many answers. I guess I'll file an improvement request. I think
> I'm going to put it into the maven-scm-plugin tracker (
> http://jira.codehaus.org/browse/SCM).
> What do you think?
> 
> Cheers.
> 
> 2009/5/4 Baptiste MATHUS 
> 
> > Hi all,
> >
> > I'm looking for a simple a quick way to update my scm tags. I'm currently
> > refactoring my projects, and I find it cumbersome to manually update ths scm
> > tag to the new although the information is already present in the svn
> > metadata.
> >
> > I took a quick look at scm:*** goals but can't find the one that fits my
> > need corresponding (moreover I think this plugin is more designed to be used
> > as a dependency to front-end plugin, so there's not a lot documentation for
> > each goals :)).
> >
> > What I'd like is a goal that would retrieved the "svn info ." command
> > output and update the <*connection> tags in the pom. Does this goal
> > already exist or should I file an improvement request about it?
> >
> > Thanks a lot.
> >
> > Cheers.
> >
> > --
> > Baptiste MATHUS - http://batmat.net
> > Sauvez un arbre,
> > Mangez un castor !
> 
> 
> 
> 
> -- 
> Baptiste MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !





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

Re: scm:add question

[Mark Struberg]

Hi!

The short answer is: why not simply call git-add [files], git-commit, git-push ?

If you use SVN you also wouldn't use mvn scm:add, isn't?


The long answer is: I honestly have no clue why this happens :)
I get the fileSet.getFileList() in the executeAddCommand and simply add all the 
files in it to the git-add command line. (we could add a '--' for safety 
reasons btw)

So I' need a bit more debug output via mvn -X.
A JIRA would also be nice :)
And this should btw go to the scm list to not scare users with internal stuff ;)

LieGrue,
strub

--- Ryan Connolly  schrieb am Mi, 22.4.2009:

> Von: Ryan Connolly 
> Betreff: Re: scm:add question
> An: "Maven Users List" 
> Datum: Mittwoch, 22. April 2009, 15:12
> How about using */** for
> includes?  Also, maybe run using -e to see
> the stack trace if available?  That may help you debug
> this issue as
> well.
> 
> On Wed, Apr 22, 2009 at 9:00 AM, Sean Davis 
> wrote:
> > On Wed, Apr 22, 2009 at 8:40 AM, Ryan Connolly 
> wrote:
> >
> >> It looks as though you are trying to add
> everything in the src dir but
> >> the plugin is complaining that it does not know
> what it is you want to
> >> add... I would try passing the optional includes
> property to the
> >> plugin configuration to see if that changes
> things.
> >
> >
> > Thanks, Ryan, for the suggestion.
> >
> >  mvn scm:add -Dmaven.scm.basedir=./src
> -Dmaven.scm.src.includes=*
> >
> > produces the same result.
> >
> > Sean
> >
> >
> >>
> >> On Wed, Apr 22, 2009 at 8:27 AM, Sean Davis 
> wrote:
> >> > I am pretty new to maven and I am trying to
> use the maven scm plugin to
> >> add
> >> > files and then commit to a bare git
> repository (located on the file
> >> system).
> >> >
> >> > In my pom, I have:
> >> >
> >> >    
> >> >      
>  scm:git:file://localhost/tmp/stuff.git
> >> >
> >> >
> >>
> scm:git:file://localhost/tmp/stuff.git
> >> >    
> >> >
> >> > Then, I am executing from the command line
> and in the base directory of
> >> the
> >> > project (directory contains pom.xml):
> >> >
> >> > sdavis$ mvn scm:add
> -Dmaven.scm.basedir=./src
> >> > [INFO] Scanning for projects...
> >> > [INFO] Searching repository for plugin with
> prefix: 'scm'.
> >> > [INFO]
> >> >
> 
> >> > [INFO] Building SeqWrench
> >> > [INFO]    task-segment: [scm:add]
> (aggregator-style)
> >> > [INFO]
> >> >
> 
> >> > [INFO] [scm:add]
> >> > [INFO]
> >> >
> 
> >> > [ERROR] BUILD ERROR
> >> > [INFO]
> >> >
> 
> >> > [INFO] Cannot run add command :
> >> >
> >> > Embedded error: Exception while executing SCM
> command.
> >> > You must provide at least one file/directory
> to add
> >> >
> >> > Any suggestions on what I am missing?
> >> >
> >> > Thanks,
> >> > Sean
> >> >
> >>
> >>
> >>
> >> --
> >> �...@n
> >>
> >>
> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> 
> 
> 
> -- 
> �...@n
> 
> -
> 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: Is there a way to verify/check/repair a local repository ?

[Mark Struberg]

have you checked if it isn't only the META-INF/maven contents?

LieGrue,
strub

--- Tim  schrieb am Di, 17.3.2009:

> Von: Tim 
> Betreff: Re: Is there a way to verify/check/repair a local repository ?
> An: "Maven Users List" 
> Datum: Dienstag, 17. März 2009, 16:04
> I'm actually having the same
> problem.After alot of debugging I noticed
> something interesting.
> 
> -rw-r--r-- 1 tich tich 1482491
> common-util-25-20090313.151759-9.jar
> -rw-r--r-- 1 tich tich 1482490
> common-util-25-20090317.001243-13.jar
> -rw-r--r-- 1 tich tich 1482491 common-util-25-SNAPSHOT.jar
> 
> I've snipped out all the non relevant info. Notice the size
> of -SNAPSHOT?
> It is actually different from the size of the latest
> released version
> (snapshot -13).
> Since the -SNAPSHOT jar is used in the classpath instead of
> the
> actual -2009xxx.  versions it will fail the
> build.
> It seems that something in maven's mechanism for replacing
> the SNAPSHOT jars
> will occasionally break. I haven't had time to look into
> exactly what it is
> but this is likely the source of your build errors. Notice
> that this only
> effects -SNAPSHOT jars so I don't know if that is true in
> your scenario.
> 
> On Tue, Mar 17, 2009 at 8:56 AM, Julien CARSIQUE wrote:
> 
> > Hello,
> >
> > I had issues building my project but strangely it was
> building fine on
> > other computers.
> > So, I tried the following steps:
> >   mv ~/.m2/repository
> ~/.m2/repository.old
> >   => build ok
> >   mv ~/.m2/repository
> ~/.m2/repository.new && mv ~/.m2/repository.old
> > ~/.m2/repository && cp -rf
> ~/.m2/repository.new/* ~/.m2/repository/
> >   => build ok
> >
> > Using diff, I saw that a few files differ (xml, pom,
> jar, sha1, ...) so it
> > seems there was something "broken" in my local
> repository. Deleting it is
> > not a very convenient solution.
> > Is there a way to verify/check/repair a local
> repository (I tried -U option
> > without success) ?
> >
> > Thanks,
> >
> > --
> > Julien Carsique, Nuxeo (Paris, France)
> > www.nuxeo.com - The Open Source ECM Platform -
> www.nuxeo.org
> > Nuxeo ECM Stack - The Java EE, scalable,
> standard-based ECM Platform
> > jcarsi...@nuxeo.com
> | Tel: +33 1 40 33 79 87
> >
> >
> >
> >
> -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> 
> 
> 
> -- 
> 
> Joan Rivers  - "I knew I was an unwanted baby when I
> saw that my bath toys
> were a toaster and a radio."
> 




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

Re: "Un-mavenize" a Maven2 project ?

[Mark Struberg]

All they have to do is unziping the maven.zip and set the PATH.

Really, all other options - _including_ manual eclipse project config and ANT 
setup - are _much_  more time consuming than this.

You don't even have to give them a share and create a logon for each of the 
students. Simply direct them to 
http://maven.apache.org/download

LieGrue,
strub

--- Ian Petzer  schrieb am Sa, 28.2.2009:

> Von: Ian Petzer 
> Betreff: Re: "Un-mavenize" a Maven2 project ?
> An: "Maven Users List" 
> Datum: Samstag, 28. Februar 2009, 21:25
> Hi Alessio,
> 
> A possible solution to your problem that would allow you to
> keep your
> mavenised project and isolate your students from Maven
> would be:
> 
> 1) Generate an eclipse project using Maven
> 2) Create a lib folder in your project structure (at the
> same level as src)
> 3) Manually or automatically copy the the project
> dependencies from your
> local repo into the lib folder (maintaining their relative
> directory
> structures)
> 4) Distribute the project to your students. Each of them
> will have to use
> the 'Import existing eclipse project' option to get
> it into their workspace.
> 5) All of the project dependencies are mapped relative to
> the M2_REPO
> variable, so your students would have to create this
> variable and then point
> it at the lib folder containing the dependencies.
> 
> By this point they should be up and running and ready to
> code.
> 
> I haven't tried this but I think it should work fine.
> You could also
> distribute the lib folder seperately to the project if you
> preferred that.
> 
> Ian
> 
> 
> 
> 
> On Fri, Feb 27, 2009 at 6:44 PM, Mark Struberg
>  wrote:
> 
> > but ant must be installed also before it can be used.
> And installing ant is
> > the same effort than installing maven.
> > So this will not add anything to his problem.
> >
> > LieGrue,
> > strub
> >
> >
> > --- David Weintraub  schrieb
> am Fr, 27.2.2009:
> >
> > > Von: David Weintraub 
> > > Betreff: Re: "Un-mavenize" a Maven2
> project ?
> > > An: "Maven Users List"
> 
> > > Datum: Freitag, 27. Februar 2009, 19:18
> > > Would Ant be okay to use?
> > >
> > > You don't have to demavenize a thing -- just
> add a
> > > build.xml to your project.
> > >
> > > We converted many of our projects from Ant to
> Maven, but
> > > still have
> > > both the build.xml and pom.xml in the root
> directory. I
> > > even removed
> > > the third party jars from our repository.
> Instead, I added
> > > Ant's 
> > > task to the build.xml to fetch the needed jars.
> It is up to
> > > the tech
> > > leads to decide whether to use Maven or Ant in
> our
> > > continuous build
> > > process although more and more projects are now
> being built
> > > with
> > > Maven.
> > >
> > > Then again, installed Maven, set the settings.xml
> in the
> > > Maven
> > > directory, then tarred it up and pass it out to
> the
> > > students. It's
> > > pretty self contained. All they need to do is
> untar it
> > > somewhere, and
> > > put a link to the "mvn" script into
> their PATH.
> > > That will allow the
> > > students to learn Maven while they are at it.
> > >
> > > Might as well let your students learn how to use
> Maven now
> > > while their
> > > brains are still soft and moist rather than wait
> a few
> > > years after
> > > brain hardening has started to set in.
> > >
> > > On Fri, Feb 27, 2009 at 2:19 AM, Alessio Pace
> > >  wrote:
> > > > Hi,
> > > >
> > > > a project I'm working on is built by
> Maven2. It is
> > > a single module, it uses
> > > > M2 merely for dependency managament.
> > > >
> > > > I have to let some students play with it as
> part of a
> > > lab project. Their
> > > > machines just have plain Eclipse, and the
> users are
> > > Maven-unaware, and I
> > > > can't afford to make them pre-install
> Maven or
> > > install it during the lab
> > > > session (too few hours).
> > > >
> > > > What I wanted to do is to
> "un-mavenize" the
> > > project, creating a separate
> > > > source tree in the old fashion: without the
> pom.xml
> > > but with a libs
> > > &

Re: "Un-mavenize" a Maven2 project ?

[Mark Struberg]

but ant must be installed also before it can be used. And installing ant is the 
same effort than installing maven. 
So this will not add anything to his problem.

LieGrue,
strub


--- David Weintraub  schrieb am Fr, 27.2.2009:

> Von: David Weintraub 
> Betreff: Re: "Un-mavenize" a Maven2 project ?
> An: "Maven Users List" 
> Datum: Freitag, 27. Februar 2009, 19:18
> Would Ant be okay to use?
> 
> You don't have to demavenize a thing -- just add a
> build.xml to your project.
> 
> We converted many of our projects from Ant to Maven, but
> still have
> both the build.xml and pom.xml in the root directory. I
> even removed
> the third party jars from our repository. Instead, I added
> Ant's 
> task to the build.xml to fetch the needed jars. It is up to
> the tech
> leads to decide whether to use Maven or Ant in our
> continuous build
> process although more and more projects are now being built
> with
> Maven.
> 
> Then again, installed Maven, set the settings.xml in the
> Maven
> directory, then tarred it up and pass it out to the
> students. It's
> pretty self contained. All they need to do is untar it
> somewhere, and
> put a link to the "mvn" script into their PATH.
> That will allow the
> students to learn Maven while they are at it.
> 
> Might as well let your students learn how to use Maven now
> while their
> brains are still soft and moist rather than wait a few
> years after
> brain hardening has started to set in.
> 
> On Fri, Feb 27, 2009 at 2:19 AM, Alessio Pace
>  wrote:
> > Hi,
> >
> > a project I'm working on is built by Maven2. It is
> a single module, it uses
> > M2 merely for dependency managament.
> >
> > I have to let some students play with it as part of a
> lab project. Their
> > machines just have plain Eclipse, and the users are
> Maven-unaware, and I
> > can't afford to make them pre-install Maven or
> install it during the lab
> > session (too few hours).
> >
> > What I wanted to do is to "un-mavenize" the
> project, creating a separate
> > source tree in the old fashion: without the pom.xml
> but with a libs
> > directory filled with all the jars my project depends
> on. Possibly also with
> > the Eclipse .project and .classpath files already
> configured (ok ok, this is
> > optional).
> >
> > Thanks in advance for any suggestion on how to achieve
> that, or with
> > comments if you ever had to deal with such a situation
> (and possibly if you
> > want me to discourage to go with the un-mavenize
> process)
> >
> > Regards,
> > Alessio Pace.
> >
> 
> 
> 
> -- 
> --
> David Weintraub
> qazw...@gmail.com
> 
> -
> 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: "Un-mavenize" a Maven2 project ?

[Mark Struberg]

Allessandro, 

just my opinion (as a former student and as someone who holds lessons from time 
to time):

Since maven nowadays is really a standard tool in the java world which almost 
_everyone_ uses, it would be a good point to introduce it to your students.
Also other ways fumbling around with eclipse config are much more time 
consuming than downloading maven.zip.

LieGrue,
strub

--- Alessio Pace  schrieb am Fr, 27.2.2009:

> Von: Alessio Pace 
> Betreff: Re: "Un-mavenize" a Maven2 project ?
> An: "Maven Users List" 
> Datum: Freitag, 27. Februar 2009, 8:43
> On Fri, Feb 27, 2009 at 8:36 AM, Ketan Khairnar
> wrote:
> 
> > simple solution would be to include classpath-entry 
> in .classpath eclipse
> > file
> >
> > e.g.
> >
> > * combineaccessrules="false" kind="src"
> > path="/DependencyProject"/>*
> 
> 
> 
> I don't know if we are talking about the exact use case
> I was referring to.
> I would like to have re-create a project source tree with a
> directory of
> libraries (the jars) my current project depend on, and have
> these jars
> inside this source tree (not just in my $M2 repository).
> 
> I know I can do maven eclipse:eclipse and then copy the
> files listed in the
> .classpath into my source tree, but I was wondering only if
> there was a more
> custom solution for this.
> 
> Thank you anyway.
> 
> Regards,
> Alessio Pace.
> 
> 
> >
> >
> >
> > On Fri, Feb 27, 2009 at 1:03 PM, Alessio Pace
>  > >wrote:
> >
> > > On Fri, Feb 27, 2009 at 8:24 AM, Ketan Khairnar
> <
> > ketan.khair...@gmail.com
> > > >wrote:
> > >
> > > > write a ant script to move maven project to
> new directory with standard
> > > > eclipse project format.
> > > >
> > > > Once you open a project in eclipse
> class-path entries can be added.
> > > >
> > > > this is partial automation though
> > >
> > >
> > >
> > > Hi,
> > >
> > > thanks for your answer. I was wondering, but what
> about dependency
> > > resolution?
> > >
> > > Regards,
> > > Alessio Pace.
> > >
> > >
> > >
> > > >
> > > >
> > > > On Fri, Feb 27, 2009 at 12:49 PM, Alessio
> Pace  > > > >wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > a project I'm working on is built
> by Maven2. It is a single module,
> > it
> > > > uses
> > > > > M2 merely for dependency managament.
> > > > >
> > > > > I have to let some students play with
> it as part of a lab project.
> > > Their
> > > > > machines just have plain Eclipse, and
> the users are Maven-unaware,
> > and
> > > I
> > > > > can't afford to make them
> pre-install Maven or install it during the
> > > lab
> > > > > session (too few hours).
> > > > >
> > > > > What I wanted to do is to
> "un-mavenize" the project, creating a
> > > separate
> > > > > source tree in the old fashion: without
> the pom.xml but with a libs
> > > > > directory filled with all the jars my
> project depends on. Possibly
> > also
> > > > > with
> > > > > the Eclipse .project and .classpath
> files already configured (ok ok,
> > > this
> > > > > is
> > > > > optional).
> > > > >
> > > > > Thanks in advance for any suggestion on
> how to achieve that, or with
> > > > > comments if you ever had to deal with
> such a situation (and possibly
> > if
> > > > you
> > > > > want me to discourage to go with the
> un-mavenize process)
> > > > >
> > > > > Regards,
> > > > > Alessio Pace.
> > > > >
> > > >
> > >
> >




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

[ANN] OpenJPA Maven Plugin 1.0 Released

[Mark Struberg]

The Maven team is pleased to announce the release of the

openjpa-maven-plugin-1.0


The plugin documentation can be found here:

http://mojo.codehaus.org/openjpa-maven-plugin/



The following issues have been resolved:

http://jira.codehaus.org/browse/MOJO-1132
http://jira.codehaus.org/browse/MOJO-1267
http://jira.codehaus.org/browse/MOJO-1133
http://jira.codehaus.org/browse/MOJO-1134
http://jira.codehaus.org/browse/MOJO-1165
http://jira.codehaus.org/browse/MOJO-1305


NOTE: the plugin uses openjpa-1.2.0 as default! If you like to use the plugin 
with another openjpa version, you can simply add a  section with 
your desired version to the plugin definition.


LieGrue,
The Maven team

PS: feel free to contact me if there are any wishes left open :)





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