Re: Can I prevent maven from searching dependencies in localRepository?
sounds like you are not using versions correctly. -SNAPSHOT versions are for untested local stuff. non-SNAPSHOT versions are pulled from repositories and have been tested. They are only produced from a build machine, so no developer should have a non-SNAPSHOT version unless it came from a remote repo 2009/6/17 gorgophol : > > > > Matt Brown-20 wrote: >> >> Why would you want Maven to NOT use the local repository? I believe it >> does this so that every single goal/phase (compile, test, etc) does not >> need to re-fetch artifacts it has already seen from the network. >> > > As mentioned in my question, there are several repositories, which provide > all the artifacts a special group of developers is allowed to use. They can > use their own artifacts, stored in there own repository, external artifacts, > provided by a repository for external jars, and other (company-) internal > artifacts, created by other developer groups, but ONLY in case they think > the artifacts are reusable. So they (as the creators of a specific artifact) > have to decide which artifact in which version is usable by other groups, > and so they deploy this version of a artifact into the "share"-repository S. > Thats the scenario software-development is organized in my company. > > So just for explanation: If artifact A is just built and NOT deployed into > S, it's nevertheless usable, because maven looks into localRepository. But A > IS NOT tested and NOT thought for use in other project-contexts. Thats why > I'd like to prevent maven from fetching artifacts from localRepository. It > should just use all the repository I tell maven a specific user/group IS > ALLOWED to use. If there is no possibility, I'd have to set up a > maven-instance for every group of developers, instead of using one central > installation for all groups and seperate them with different repositories > and profiles. > > -- > View this message in context: > http://www.nabble.com/Can-I-prevent-maven-from-searching-dependencies-in-localRepository--tp24054742p24067791.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 I prevent maven from searching dependencies in localRepository?
Matt Brown-20 wrote: > > Why would you want Maven to NOT use the local repository? I believe it > does this so that every single goal/phase (compile, test, etc) does not > need to re-fetch artifacts it has already seen from the network. > As mentioned in my question, there are several repositories, which provide all the artifacts a special group of developers is allowed to use. They can use their own artifacts, stored in there own repository, external artifacts, provided by a repository for external jars, and other (company-) internal artifacts, created by other developer groups, but ONLY in case they think the artifacts are reusable. So they (as the creators of a specific artifact) have to decide which artifact in which version is usable by other groups, and so they deploy this version of a artifact into the "share"-repository S. Thats the scenario software-development is organized in my company. So just for explanation: If artifact A is just built and NOT deployed into S, it's nevertheless usable, because maven looks into localRepository. But A IS NOT tested and NOT thought for use in other project-contexts. Thats why I'd like to prevent maven from fetching artifacts from localRepository. It should just use all the repository I tell maven a specific user/group IS ALLOWED to use. If there is no possibility, I'd have to set up a maven-instance for every group of developers, instead of using one central installation for all groups and seperate them with different repositories and profiles. -- View this message in context: http://www.nabble.com/Can-I-prevent-maven-from-searching-dependencies-in-localRepository--tp24054742p24067791.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
Re: Plugin / Tool for local repository
On Mon, Jun 15, 2009 at 11:38 AM, Mohan KR wrote: > same here, interested in any updates on the plugin from the discussion > below. Don't want to whip out another one > if it already exists. The code definitely exists -- Apache Continuum has a feature that purges the local repo used for builds: http://continuum.apache.org/docs/1.3.3/administrator_guides/purgeConfiguration.html I don't know that it's been wrapped in a plugin though. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency version at pom level
doh! you're absolutely correct zac. i misinterpeted something i read in "maven: the definitive guide". on the bottom of page 106 in a section describing dependencyManagement it reads: Once these are moved up, we need to remove the versions for these dependencies from each of the POMs; otherwise, they will override the dependencyManagement defined in the parent project. so i was thinking using dependencyManagement for my use case wouldn't work unless the version wasn't specified in the dependent poms, but i guess the above statement only applies to pom inheritance relationships, versus pom dependency relationships. so i'm all set on this, thanks again! Zac Thompson wrote: > > On Mon, Jun 15, 2009 at 6:54 PM, tony k wrote: >> the general use case is that you are working with a series of third-party >> dependencies >> (and their respective poms) that specify conflicting versions of a >> particular >> library commons-logging for example, and you want to force a specific >> version >> that you know you will be running with. let's say you want to verify >> behavior >> of those third party dependencies with this specific version using the >> test >> goal. > > Perhaps I am misunderstanding your question, but I think the > dependecyManagement section in fact does exactly what you want: > enforce versions of dependencies. Specify the following section in a > common parent for your artifacts, mvn install, and you should be done > (I used version 1.1 for the sake of example): > > > > commons-logging > commons-logging > 1.1 > > ... > > > You can visually test the result using 'mvn help:effective-pom' or > 'mvn dependency:tree'. > > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > > "Dependency management - this allows project authors to directly > specify the versions of artifacts to be used when they are encountered > in transitive dependencies or in dependencies where no version has > been specified. ... A can include D as a dependency in its > dependencyManagement section and directly control which version of D > is used when, or if, it is ever referenced." > > Controlling versions through dependencyManagement is a good idea > (combined with parent POMs, dare I say a "best practice"). Handling > this stuff is one of maven's key strengths; it was designed for this > general use case. No surprise that this is "one of the first things" > you asked yourself :) > > You would only *need* to use exclusions if you didn't want the > dependency at all. If that were true, then yes, I think you would > have to do it for each artifact that specified it as a direct > dependency. > > Zac > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > -- View this message in context: http://www.nabble.com/dependency-version-at-pom-level-tp24046046p24066287.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
Re: Run a war/set of wars released in internal repo
It's a simple matter to create a self-executable war, either with Jetty or Winstone. I'd remove Maven from the equation and just give an url to the repository. If you want, you could also publish a jnlp file with the war so he really wouldn't need to do anything else but click on the link to start the app. Kalle On Tue, Jun 16, 2009 at 6:57 PM, Clifton wrote: > > Skinny pom is a hack. What I'd like to do is have him run my project > directly. Sharing a pom requires too many steps. You have to detach the pom > from the email, save it sin an empty folder such that it doesn't conflict > with other things (conflicts are not likely the first few times but possible > when I get happy and start using the idea more often with more advanced > people), run the command, then diagnose why it didn't work on the first > attempt. (Was there corruption in the detached email? Is there an XSD in the > pom trying to resolve to a absolute path on my machine? Did I mis-type a > dependency in the pom or forget to close a tag?) I'm leaning towards using > an assembly which describes the Tomcat structure since there's likely two > war apps involved but even then there's no straight forward way to unpack a > tomcat tar and launch on a single command. I'm looking for something like an > executable war or a jar in a war or something. Maybe I'll whip up something > quick/dirty in Groovy that embodies the idea and release it. I was just > checking to see if it had been done or if there was an alternate approach. > > > Stephen Connolly-2 wrote: >> >> you could give him a skinny pom that has the deployed war as a dependency. >> >> war packaging will pull down the dependency and merge it with your >> (empty) skinny pom >> >> in which case you just need to give him the skinny pom file. this is >> extra nice as you can configure jetty defaults in the skinny pom and >> define a default goal so all he needs to do is run "mvn" >> >> On 16/06/2009, Clifton wrote: >>> >>> I gotta believe by now there is a slick way to run a war file released to >>> an >>> internal repository under a plugin like jetty or cargo. I'd like to be >>> able >>> to share a set of web-apps I created with a colleague without him needing >>> to >>> download my source. Something like "Just run 'mvn >>> -DreleasedWar=com.mycompany:mywarproj:1.2 jetty:run' from the command >>> line" >>> would be a nice way to share work I've done. The idea would be the plugin >>> resolves the war dependency using typical dependency resolve logic and >>> spins >>> up the container pointing to the war file in the local repo. Maybe it >>> would >>> copy from the local repo into the default build 'targeet' dir or >>> something. >>> has there ever been something like this done? \ >>> >>> - >>> Cliff >>> http://codeforfun.wordpress.com >>> http://www.nabble.com/file/u156847/Cliff-in-the-lab.png >>> -- >>> View this message in context: >>> http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24061123.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 >> >> >> > > > - > Cliff > http://codeforfun.wordpress.com > http://www.nabble.com/file/u156847/Cliff-in-the-lab.png > -- > View this message in context: > http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24065719.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: Run a war/set of wars released in internal repo
Skinny pom is a hack. What I'd like to do is have him run my project directly. Sharing a pom requires too many steps. You have to detach the pom from the email, save it sin an empty folder such that it doesn't conflict with other things (conflicts are not likely the first few times but possible when I get happy and start using the idea more often with more advanced people), run the command, then diagnose why it didn't work on the first attempt. (Was there corruption in the detached email? Is there an XSD in the pom trying to resolve to a absolute path on my machine? Did I mis-type a dependency in the pom or forget to close a tag?) I'm leaning towards using an assembly which describes the Tomcat structure since there's likely two war apps involved but even then there's no straight forward way to unpack a tomcat tar and launch on a single command. I'm looking for something like an executable war or a jar in a war or something. Maybe I'll whip up something quick/dirty in Groovy that embodies the idea and release it. I was just checking to see if it had been done or if there was an alternate approach. Stephen Connolly-2 wrote: > > you could give him a skinny pom that has the deployed war as a dependency. > > war packaging will pull down the dependency and merge it with your > (empty) skinny pom > > in which case you just need to give him the skinny pom file. this is > extra nice as you can configure jetty defaults in the skinny pom and > define a default goal so all he needs to do is run "mvn" > > On 16/06/2009, Clifton wrote: >> >> I gotta believe by now there is a slick way to run a war file released to >> an >> internal repository under a plugin like jetty or cargo. I'd like to be >> able >> to share a set of web-apps I created with a colleague without him needing >> to >> download my source. Something like "Just run 'mvn >> -DreleasedWar=com.mycompany:mywarproj:1.2 jetty:run' from the command >> line" >> would be a nice way to share work I've done. The idea would be the plugin >> resolves the war dependency using typical dependency resolve logic and >> spins >> up the container pointing to the war file in the local repo. Maybe it >> would >> copy from the local repo into the default build 'targeet' dir or >> something. >> has there ever been something like this done? \ >> >> - >> Cliff >> http://codeforfun.wordpress.com >> http://www.nabble.com/file/u156847/Cliff-in-the-lab.png >> -- >> View this message in context: >> http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24061123.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 > > > - Cliff http://codeforfun.wordpress.com http://www.nabble.com/file/u156847/Cliff-in-the-lab.png -- View this message in context: http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24065719.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
Re: Quandary over testing support classes.
Barrie Treloar wrote: > You have a cyclic dependency. > The solution is to break the cycle. > There isn't another way. > > Your choices on breaking it are: > * Move TestSupport into Model (not ideal) > * Move the code in Model that TestSupport relies upon into its own module. > Yeah, that's what I figured the answer would be, and I've already implemented the 2nd option you mentioned here. It was worth a shot to see if anyone had any other solutions, though. Thanks for all the input! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
On Wed, Jun 17, 2009 at 1:46 AM, David C. Hicks wrote: > > Barrie Treloar wrote: >> I think I see what you are saying. >> >> Model (test) depends upon Test Support (main and test jars) >> I am going to assume that Test Support does not depend upon Model >> (either main or test) >> > Almost, but not quite. TestSupport does depend on Model, because it > includes the Builder classes that create Model objects for unit and > functional tests. It just works out that some of the more complex unit > tests for Model classes *also* use the builders. So, Model must be > built before TestSupport, and TestSupport depends on Model. I just have > these few unit tests that really belong in the Model module but are > currently in the TestSupport module because of their dependencies on the > builders. > > I've only been able to see a few ways out of this: > > 1) Move business logic out of the Model and into some intermediate > module. (This moves me away from an OO paradigm. IMO) > 2) Rewrite my Model unit tests so that they don't use builders. (This > makes the tests less readable/maintainable.) > 3) Create a new module that is nothing more than just the unit tests on > the Model module. Then dependencies can be resolved pretty easily. > 4) Keep it as I have it now, with a few "special" Model unit tests > living in the TestSupport module. (I don't like this. I think it will > cause confusion in the future.) > > I just figured that I couldn't possibly be the first person to run into > this problem. So, I was curious how others resolved it. You have a cyclic dependency. The solution is to break the cycle. There isn't another way. Your choices on breaking it are: * Move TestSupport into Model (not ideal) * Move the code in Model that TestSupport relies upon into its own module. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Plugin / Tool for local repository
We use a scheduled task that runs a Ruby program to delete our local repository
if it is older than a week. You could manipulate this to only delete
snapshots, but I prefer to get everything fresh to make sure our internal
mirror is working correctly. The full version of this program (not included)
also does nifty chores such as defragging and updating Subversion directories.
If you're interested in more admin tasks with Ruby I suggest:
http://www.pragprog.com/titles/bmsft/everyday-scripting-with-ruby
Here's the Ruby code snippet to blast the maven repository:
#Delete the local maven repository if it is older than a week
m2_repo = "c:\\path\\to\\your\\maven\\repo"
if File.exists?(m2_repo)
one_week_in_seconds = 604800
dir_age = start - File.ctime(m2_repo)
if (dir_age > one_week_in_seconds)
puts "#{m2_repo} was created #{dir_age} seconds ago."
puts "Deleting #{m2_repo}"
FileUtils.rm_rf(m2_repo)
puts "Finished deleting #{m2_repo}"
else
puts "Skipped deleting #{m2_repo} it's only #{dir_age} seconds
old"
end
"No directory #{m2_repo}"
end
-Original Message-
From: Mohan KR [mailto:kmoh@gmail.com]
Sent: Monday, June 15, 2009 1:38 PM
To: 'Maven Users List'
Subject: RE: Plugin / Tool for local repository
same here, interested in any updates on the plugin from the discussion
below. Don't want to whip out another one
if it already exists.
Thanks,
mohan kr
-Original Message-
From: Henri Gomez [mailto:henri.go...@gmail.com]
Sent: Monday, June 15, 2009 9:32 AM
To: Maven Users List
Subject: Re: Plugin / Tool for local repository
I saw an interested thread on mojo-dev about a local repository purge
plugin.
http://www.nabble.com/local-repository-purge-plugin-td16937047.html
Any one know it status ?
2009/6/15 Henri Gomez :
> Good stuff but I also needed the various versions of the project to be
removed.
>
>
>
> 2009/6/15 Anders Hammar :
>>
http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-reposito
ry-mojo.html
>>
>> /Anders
>>
>> On Mon, Jun 15, 2009 at 10:46, Henri Gomez wrote:
>>> Hi to all,
>>>
>>> I wonder if there is a plugin/tool available to clean a local repository
?
>>>
>>> After some time repository could became huge with many snapshots or
>>> versions (when using ranges) and the only way, for now, is just to
>>> clean up by hand.
>>>
>>> Repository managers like Nexus or Archiva does this cleanup, that's
>>> why I wonder if such service could exist in a maven plugin.
>>>
>>> Regards
>>>
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom
they are addressed. If you have received this e-mail in error please notify the
originator of the message. This footer also
confirms that this e-mail message has been scanned for the presence of computer
viruses. Any views expressed in this message are
those of the individual sender, except where the sender specifies and with
authority, states them to be the views of Iowa Student
Loan.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven, M2Eclipse, Nexus @ Eclipse DemoCamp in Budapest
Also, two of us will be at University of Szeged on Friday 19th, doing the same "we'll be doing some demos and chatting with folks". The beer will came later, most probably at the evening. Anyone around, interested to attend the presentation at University, do some chat and/or beer should contact me directly on my mail, since exact times and pubs are not known yet. Thanks, ~t~ On Sun, Jun 14, 2009 at 9:51 AM, Jason van Zyl wrote: > Hi, > > Tamás Cservenák and me will be at the Eclipse DemoCamp on Thursday June > 18th. If you're interested in M2Eclipse, Maven or Nexus we'll be doing some > demos and chatting with folks. Beer will most likely be involved afterward > :-) > > http://wiki.eclipse.org/Eclipse_DemoCamps_Galileo_2009/Budapest > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/SonatypeNexus > http://twitter.com/SonatypeM2E > -- > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > > - > 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: [ANNOUNCEMENT] - UNIX Maven Plugin 1.0-alpha-4 released
+1 On Tue, Jun 16, 2009 at 9:17 AM, Paul Benedict wrote: > I think a much better name would be the Unix Packaging Maven Plugin. > > Sorry, but without an adjective, it doesn't clearly say what the plugin > does. > > 2009/6/15 Trygve Laugstøl : > > I'm happy to announce the fourth alpha release of unix-maven-plugin. > > This is still primarily a technology preview, but is fully functional. > > > > = New in this release = > > > > o support for creating "zip" archives > > o added support for classes for pkg > > o %doc and %config for RPM > > o Lots of documentation, including a PDF. > > > > == Technical changes == > > > > MUNIX-18: Simplify the script mechanism > > MUNIX-17: Document how versions and revisions are calculated > > MUNIX-16: Document how the scripts directories work > > MUNIX-15: Improve error message when an artifact is not found > > MUNIX-12: Add support for creating zip files > > MUNIX-6: set-attributes doesn't pick up paths that aren't explicitly > > created with mkdirs (Filed by Marius Gravdal > > MUNIX-4: Add support for the %doc directive for RPM (filed by Erik > > Drolshammer) > > MUNIX-3: Add support for the %config directive for RPM (filed by Erik > > Drolshammer) > > MUNIX-1: the "release" portion of the rpm does not have to be an int > > (filed by Brett Okken) > > > > = About the plugin = > > > > The unix-maven-plugin is a Maven plugin for producing installation > > packages for UNIX platforms. > > > > The current release is 1.0-alpha-4. This release is meant as a > > technology preview release. The plugin is useful but work is in progress > > to make sure it support even more use cases. > > > > The plugin has gained a substantial amount of documentation, available > > at [1]. > > > > The plugin combines the work of the deb, solaris and rpm Maven plugins > > and also handles the aspect of assembling the packages without using the > > assembly plugin. > > > > Supported platforms: > > > > * Debian (.deb) > > * RedHat and Fedora (.rpm) > > * SysV packages for Solaris (.pkg) > > * Generic Zip files (.zip) > > > > The development happens on the Codehaus Mojo project [2], if you want to > > try it out, have found an issue or just want your use case supported get > > in touch through the mailing lists [3]. > > > > [1]: http://mojo.codehaus.org/unix/usage.html > > [2]: http://mojo.codehaus.org/unix/ > > [3]: http://mojo.codehaus.org/unix/mail-lists.html > > > > - > > 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: Quandary over testing support classes.
Matt Brown wrote: > Is it possible for you to refactor the TestSupport classes that the Model > unit tests depend on into a third artifact, which both projects (Model and > TestSupport) can then rely on (with scope=testing)? > That's essentially what I've been working on the last hour or so. So, now the dependency chain looks something like this: Model -> TestSupport -> ModelTesting > As others have pointed out circular dependencies like this are a bad design. > I don't think of this as a circular dependency, because it's only a problem in the test scope. None of the core code exhibits any problem like this. It's simply caused by the convenience classes used for test purposes. > This might be hard to really say for sure without knowing what the Model code > looks like, but I would say that if the Model core code is so > convoluted/hard-to-use that you need to employ other objects just to build > and test them, then something is off with the design of the Model - and you > could probably re-design those classes to make a lot of things easier. > It's not so much a case of the classes being convoluted. When you get to higher levels, though, it becomes tedious to write test code without some helper classes. Example: - Customer has a collection of Sites. Site has a collection of Machines. Machine has a collection of Tasks. So, we use these Builder classes to create larger entities (Customer) without having to rewrite the code to fill in the collections every time we create a new test case. As a result, the Builder classes must rely on the Model, and the test cases for the Model rely on the Builders. Perhaps this is a bad design from some point of view. It sure is helpful, though. I'm always open to suggestions. Thanks for the input! Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Run a war/set of wars released in internal repo
you could give him a skinny pom that has the deployed war as a dependency. war packaging will pull down the dependency and merge it with your (empty) skinny pom in which case you just need to give him the skinny pom file. this is extra nice as you can configure jetty defaults in the skinny pom and define a default goal so all he needs to do is run "mvn" On 16/06/2009, Clifton wrote: > > I gotta believe by now there is a slick way to run a war file released to an > internal repository under a plugin like jetty or cargo. I'd like to be able > to share a set of web-apps I created with a colleague without him needing to > download my source. Something like "Just run 'mvn > -DreleasedWar=com.mycompany:mywarproj:1.2 jetty:run' from the command line" > would be a nice way to share work I've done. The idea would be the plugin > resolves the war dependency using typical dependency resolve logic and spins > up the container pointing to the war file in the local repo. Maybe it would > copy from the local repo into the default build 'targeet' dir or something. > has there ever been something like this done? \ > > - > Cliff > http://codeforfun.wordpress.com > http://www.nabble.com/file/u156847/Cliff-in-the-lab.png > -- > View this message in context: > http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24061123.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
Run a war/set of wars released in internal repo
I gotta believe by now there is a slick way to run a war file released to an internal repository under a plugin like jetty or cargo. I'd like to be able to share a set of web-apps I created with a colleague without him needing to download my source. Something like "Just run 'mvn -DreleasedWar=com.mycompany:mywarproj:1.2 jetty:run' from the command line" would be a nice way to share work I've done. The idea would be the plugin resolves the war dependency using typical dependency resolve logic and spins up the container pointing to the war file in the local repo. Maybe it would copy from the local repo into the default build 'targeet' dir or something. has there ever been something like this done? \ - Cliff http://codeforfun.wordpress.com http://www.nabble.com/file/u156847/Cliff-in-the-lab.png -- View this message in context: http://www.nabble.com/Run-a-war-set-of-wars-released-in-internal-repo-tp24061123p24061123.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
Re: [PLEASE TEST] Maven 2.2.0-RC3
sorry you're having so much trouble, robert -- i just tested 2.2.0-RC3, and it worked fine for me. Good luck on IRC! On Tue, 16 Jun 2009 11:50:29 -0700 (PDT), Robert Glover wrote: > Ok, I located a DSL line that does not go through the proxy. Tomorrow > I'll bring in my personal laptop to work and use it to connect to the maven > IRC channel at irc.codehaus.org >Meanwhile, wouldn't it be nice if everyone was a good maven citizen and >downloaded the maven 2.2 RC3 and tried it out-- which by the way would >also be a help to see if anybody currently using maven 2.0.9 behind a >firewall will discover their proxy is not being recognized any longer >when they upgrade. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.0-RC3
Ok, I located a DSL line that does not go through the proxy. Tomorrow I'll bring in my personal laptop to work and use it to connect to the maven IRC channel at irc.codehaus.org Meanwhile, wouldn't it be nice if everyone was a good maven citizen and downloaded the maven 2.2 RC3 and tried it out-- which by the way would also be a help to see if anybody currently using maven 2.0.9 behind a firewall will discover their proxy is not being recognized any longer when they upgrade. - Original Message From: Robert Glover To: Maven Users List Sent: Tuesday, June 16, 2009 12:05:53 PM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I'm feeling like a poor relation watching all the happy maven users at the banquet while I stand outside, hungry, peering in. The company I work for is pretty big. My department has started using maven and a following of developers is emerging who are asking us for advice on how to use maven in their projects as well. But maven totally stopped working at this entire company for any version higher than 2.0.9. Wayne and JDCasey have tried to be helpful, but I have not been able to actually interface with JDCasy because of the firewall at work that prevents IRC and the "chat tag" that is going on for days on google chat.. Can it really be that maven is so brittle that a total failure of the proxy for an entire company occurs for the mere reason that developers upgrade from maven 2.0.9 to a higher version? How can it be that the total failure of the maven proxying happens at this pretty big company and yet no one else is reporting this? This is very disheartening. Robert - Original Message From: Robert Glover To: Maven Users List Sent: Monday, June 15, 2009 9:44:43 AM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I had Friday off, so I logged onto the maven IRC channel at home via ChatZilla, but unfortunately JDCASEY was not logged on when I tried several times. I tried again on Saturday, but again JDCASEY was not online. Today, Monday, I tried from work and found that the corporate firewell blocks IRC. I've been able to use Google IM in the past through the firewall. So, I've opened up gmail and have it on the chat page. JDCASEY, if you see this please consider sending a chat message to my gmail account. My email address there is robertglove...@gmail.com Meanwhile, I'll see I I can build the source code of maven 2.2 RC3 to have log messages to pinpoint the exact line of code causing the proxy problem. --- On Fri, 6/12/09, John Casey wrote: > From: John Casey > Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 > To: "Maven Users List" > Date: Friday, June 12, 2009, 4:18 PM > Do you have the ability to join our > IRC channel at irc.codehaus.org > (#maven) to talk more about this? If you have a > firewall/proxy in the > way of an IRC connection, you might also be able to use the > CGI client > at http://irc.codehaus.org. > > From looking at your output in the original message on > this thread, it > seems like Maven doesn't think you're supplying any > authentication > information... > > Maybe if we could talk more about this, I could help you > look for the > reason behind it all. I'm on IRC most days; my nickname is > 'jdcasey'. > > Please come find me if you have the ability, and maybe we > can figure > this out. > > Thanks, > > -john > > Robert Glover wrote: > > Below is the message from Wayne I was referring > to. Now that I have downloaded and built maven > 2.2-RC3, I guess I could put log messages into it to > pin-point the exact line of code where the proxy > fails. But already as it is, in running maven > 2.2-RC3 it already has debug level logging turned on and is > showing a lot more information than was being shown when > this problem started occuring when I upgraded from maven > 2.0.9 to maven 2.1. The sad thing is I have been > keeping this maven proxy problem to myself because we have > only been using maven for a few months. If I make it > be known that it won't work and there is no solution if we > upgrade to any version higher than maven 2.0.9, it is > likely the managers will ban maven from being used. > > -- > > > > Proxy issues are, by their very nature, almost > impossible for an > > outsider to investigate and resolve. There are > literally hundreds (or > > more) of proxy server software packages in the world, > and while they > > all more or less work for basic web browsing, most > have issues with > > various pieces of software like Maven. > > > > I won't claim to know all the changes made to the > Maven codebase from > > 2.0.9 to 2.1.0 (much less the changes in supporting > utility libraries) > > but it would seem that some change has caused your > proxy to stop > > working. If you seriously want to see this resolved, > it will probably > > take some effort on your part to get Maven and all its > libraries > > running
Multiple *.jar files from one project
We have a source tree in this format: src/main/java/com/solbright/aim/etlf/core src/main/java/com/solbright/aim/etlf/customer_1 src/main/java/com/solbright/aim/etlf/customer_2 And so on for each customer. My developers want a separate jar file for each and every customer. Not only that, but a separate assembly package for each and every customer. Do I need to create a pom.xml for each and every customer, or can I specify multiple jars in a single pom.xml? -- David Weintraub qazw...@gmail.com
Re: Quandary over testing support classes.
Matt Brown wrote: > Is it possible for you to refactor the TestSupport classes that the Model > unit tests depend on into a third artifact, which both projects (Model and > TestSupport) can then rely on (with scope=testing)? > That's essentially what I've been working on the last hour or so. So, now the dependency chain looks something like this: Model -> TestSupport -> ModelTesting > As others have pointed out circular dependencies like this are a bad design. > I don't think of this as a circular dependency, because it's only a problem in the test scope. None of the core code exhibits any problem like this. It's simply caused by the convenience classes used for test purposes. But I do, absolutely, agree with your statement - circular dependencies in the core code are bad. > This might be hard to really say for sure without knowing what the Model code > looks like, but I would say that if the Model core code is so > convoluted/hard-to-use that you need to employ other objects just to build > and test them, then something is off with the design of the Model - and you > could probably re-design those classes to make a lot of things easier. > It's not so much a case of the classes being convoluted. When you get to higher levels, though, it becomes tedious to write test code without some helper classes. Example: - Customer has a collection of Sites. Site has a collection of Machines. Machine has a collection of Tasks. So, we use these Builder classes to create larger entities (Customer) without having to rewrite the code to fill in the collections every time we create a new test case. As a result, the Builder classes must rely on the Model, and the test cases for the Model rely on the Builders. Perhaps this is a bad design from some point of view. It sure is helpful, though. I'm always open to suggestions. Thanks for the input! Dave - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Quandary over testing support classes.
Is it possible for you to refactor the TestSupport classes that the Model unit tests depend on into a third artifact, which both projects (Model and TestSupport) can then rely on (with scope=testing)? As others have pointed out circular dependencies like this are a bad design. This might be hard to really say for sure without knowing what the Model code looks like, but I would say that if the Model core code is so convoluted/hard-to-use that you need to employ other objects just to build and test them, then something is off with the design of the Model - and you could probably re-design those classes to make a lot of things easier. -Original Message- From: David C. Hicks [mailto:dhi...@i-hicks.org] Sent: Tuesday, June 16, 2009 12:17 PM To: Maven Users List Subject: Re: Quandary over testing support classes. Barrie Treloar wrote: > I think I see what you are saying. > > Model (test) depends upon Test Support (main and test jars) I am going > to assume that Test Support does not depend upon Model (either main or > test) > Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few "special" Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved 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
Clearcase with maven release plugin
Hi, I'm wondering if anyone has been able to successfully use clearcase with the maven release plugin. We're trying to figure out how to do it and investigating the various options. If you've been able get this to work, could you please share how you were able to make it work? Thanks, -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com
RE: Excluding files/webapp folder from a war
I managed to get it working (maven 2.0.9, maven-war-plugin 2.1-beta-1) with the following: ... **/*.bat,.classpath,**/*.java,pom.xml,.project,.settings/ **,**/*.sh,target/** ... Hope that helps. - Damon -Original Message- From: turbo-555 [mailto:fdur...@ticino.com] Sent: Tuesday, June 16, 2009 5:52 AM To: users@maven.apache.org Subject: Re: Excluding files/webapp folder from a war rynam0 wrote: > > Try something like this? > > > > src/main/webapp/someExcludedDirectory/** > > I removed the "war at the beginning of the pom, and tried with "mvn package war:war" (so it packages a jar and a war...) I just tried this: src/main/webapp/help/** nothing changes with src/main **/webapp/ **/help/ webapp same story...it just avoid to put a webapp and java directory in the war, but the help,static,style,...are still there basically I'd like the war to have the same contents as the jar (pretty much...) -- View this message in context: http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24 053693.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: Excluding default repositories
internal-repository [Redacted] Maven Repository http://[redacted]/artifactory/repo * However, snapshots don't seem to be resolving correctly. What else do I need to do? Stephen Connolly-2 wrote: > > Yep... point everything at your repository > > * > > FYI, you want to do this anyway as running a repository manager is pretty > much essential these days > > 2009/6/2 daniel.green > >> >> So point the proxies for the default repositories at my onsite >> repository? >> >> >> Stephen Connolly-2 wrote: >> > >> > you need to use a repository manager and have it proxy all repositories >> in >> > your settings.xml >> > >> > 2009/6/2 daniel.green >> > >> >> >> >> Is it possible to exclude default repositories? I need to ensure that >> all >> >> dependencies are taken only from the repositories that I specify. >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Excluding-default-repositories-tp23839715p23839715.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 >> >> >> >> >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Excluding-default-repositories-tp23839715p23841313.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 >> >> > > -- View this message in context: http://www.nabble.com/Excluding-default-repositories-tp23839715p24058641.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
mar files dependency in maven
Hi, I am currently trying to set up a maven build system for my project. It uses axis services which require a "mar" file for instantiation. I have added the dependency as axis2 logging 1.0 mar compile During build maven is able to download the mar file from the central repository but is not placing it in the class path which causes the execution of the unit tests to fail. Error creating bean with name 'eisjmsAxis2Configuration' defined in URL [.../saf_config.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: Factory method [public static org.apache.axis2.context.ConfigurationContext com.wellpoint.integration.saf.integration.axis2.deployment.Configuration ContextFactory.createConfigurationContextFromURIs(java.net.URL,java.net. URL) throws org.apache.axis2.AxisFault] threw exception; nested exception is org.apache.axis2.AxisFault: Trying to engage a module which is not available : logging Could anyone please point out what the issue could be and how to overcome it? I have even tried setting it in the windows system class path but still the same error comes up? Regards, Barun This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
Re: Quandary over testing support classes.
Barrie Treloar wrote: > I think I see what you are saying. > > Model (test) depends upon Test Support (main and test jars) > I am going to assume that Test Support does not depend upon Model > (either main or test) > Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few "special" Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Quandary over testing support classes.
Barrie Treloar wrote: > I think I see what you are saying. > > Model (test) depends upon Test Support (main and test jars) > I am going to assume that Test Support does not depend upon Model > (either main or test) > Almost, but not quite. TestSupport does depend on Model, because it includes the Builder classes that create Model objects for unit and functional tests. It just works out that some of the more complex unit tests for Model classes *also* use the builders. So, Model must be built before TestSupport, and TestSupport depends on Model. I just have these few unit tests that really belong in the Model module but are currently in the TestSupport module because of their dependencies on the builders. I've only been able to see a few ways out of this: 1) Move business logic out of the Model and into some intermediate module. (This moves me away from an OO paradigm. IMO) 2) Rewrite my Model unit tests so that they don't use builders. (This makes the tests less readable/maintainable.) 3) Create a new module that is nothing more than just the unit tests on the Model module. Then dependencies can be resolved pretty easily. 4) Keep it as I have it now, with a few "special" Model unit tests living in the TestSupport module. (I don't like this. I think it will cause confusion in the future.) I just figured that I couldn't possibly be the first person to run into this problem. So, I was curious how others resolved it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Maven 2.2.0-RC3
I'm feeling like a poor relation watching all the happy maven users at the banquet while I stand outside, hungry, peering in. The company I work for is pretty big. My department has started using maven and a following of developers is emerging who are asking us for advice on how to use maven in their projects as well. But maven totally stopped working at this entire company for any version higher than 2.0.9. Wayne and JDCasey have tried to be helpful, but I have not been able to actually interface with JDCasy because of the firewall at work that prevents IRC and the "chat tag" that is going on for days on google chat.. Can it really be that maven is so brittle that a total failure of the proxy for an entire company occurs for the mere reason that developers upgrade from maven 2.0.9 to a higher version? How can it be that the total failure of the maven proxying happens at this pretty big company and yet no one else is reporting this? This is very disheartening. Robert - Original Message From: Robert Glover To: Maven Users List Sent: Monday, June 15, 2009 9:44:43 AM Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 I had Friday off, so I logged onto the maven IRC channel at home via ChatZilla, but unfortunately JDCASEY was not logged on when I tried several times. I tried again on Saturday, but again JDCASEY was not online. Today, Monday, I tried from work and found that the corporate firewell blocks IRC. I've been able to use Google IM in the past through the firewall. So, I've opened up gmail and have it on the chat page. JDCASEY, if you see this please consider sending a chat message to my gmail account. My email address there is robertglove...@gmail.com Meanwhile, I'll see I I can build the source code of maven 2.2 RC3 to have log messages to pinpoint the exact line of code causing the proxy problem. --- On Fri, 6/12/09, John Casey wrote: > From: John Casey > Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 > To: "Maven Users List" > Date: Friday, June 12, 2009, 4:18 PM > Do you have the ability to join our > IRC channel at irc.codehaus.org > (#maven) to talk more about this? If you have a > firewall/proxy in the > way of an IRC connection, you might also be able to use the > CGI client > at http://irc.codehaus.org. > > From looking at your output in the original message on > this thread, it > seems like Maven doesn't think you're supplying any > authentication > information... > > Maybe if we could talk more about this, I could help you > look for the > reason behind it all. I'm on IRC most days; my nickname is > 'jdcasey'. > > Please come find me if you have the ability, and maybe we > can figure > this out. > > Thanks, > > -john > > Robert Glover wrote: > > Below is the message from Wayne I was referring > to. Now that I have downloaded and built maven > 2.2-RC3, I guess I could put log messages into it to > pin-point the exact line of code where the proxy > fails. But already as it is, in running maven > 2.2-RC3 it already has debug level logging turned on and is > showing a lot more information than was being shown when > this problem started occuring when I upgraded from maven > 2.0.9 to maven 2.1. The sad thing is I have been > keeping this maven proxy problem to myself because we have > only been using maven for a few months. If I make it > be known that it won't work and there is no solution if we > upgrade to any version higher than maven 2.0.9, it is > likely the managers will ban maven from being used. > > -- > > > > Proxy issues are, by their very nature, almost > impossible for an > > outsider to investigate and resolve. There are > literally hundreds (or > > more) of proxy server software packages in the world, > and while they > > all more or less work for basic web browsing, most > have issues with > > various pieces of software like Maven. > > > > I won't claim to know all the changes made to the > Maven codebase from > > 2.0.9 to 2.1.0 (much less the changes in supporting > utility libraries) > > but it would seem that some change has caused your > proxy to stop > > working. If you seriously want to see this resolved, > it will probably > > take some effort on your part to get Maven and all its > libraries > > running in a debugger to try to track down what is > different. > > > > Unless a ton of people start complaining about similar > problems or the > > issue can be tracked to a specific change made in > Maven (or a util > > library), I don't see this being resolved in any > well-defined > > timeframe. > > > > So, I'd stick with 2.0.9 for now. Have you tried > 2.0.10 yet? > > > > Wayne > > > > > > - Original Message > > From: John Casey > > To: Maven Users List > > Sent: Friday, June 12, 2009 10:38:30 AM > > Subject: Re: [PLEASE TEST] Maven 2.2.0-RC3 > > > > Can you tell me what Wayne's explanation was for your > proxy problem? Or, if Wayne'
RE: Can I prevent maven from searching dependencies in localRepository?
Why would you want Maven to NOT use the local repository? I believe it does this so that every single goal/phase (compile, test, etc) does not need to re-fetch artifacts it has already seen from the network. -Original Message- From: gorgophol [mailto:benjamin.h...@inter.de] Sent: Tuesday, June 16, 2009 9:47 AM To: users@maven.apache.org Subject: Can I prevent maven from searching dependencies in localRepository? Hi, I'm in trouble because of mavens localRepository. I know Maven installs everything into localRepository in install-phase, so I use the deploy-phase for bringing group-specific artifacts into group-specific repositories. Artifacts from other groups should only be usable as a dependency in the pom.xml, if they are deployed into another repository, lets call it "S" (for share). So far so good ... In settings.xml I defined several profiles, so that every group gets it's own repository and S. My problem is, that maven finds everything in localRepository. Is there any possibility to tell maven not to look into localRepository, for searching dependencies? Thanks. Benjamin -- View this message in context: http://www.nabble.com/Can-I-prevent-maven-from-searching-dependencies-in-localRepository--tp24054742p24054742.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: process-sources: process the source code, for example to filter any values.
Found this through Google: http://www.gxdeveloperweb.com/Blogs/Bram-de-Kruijff/Maven-secrets-filtering-sources.htm Not sure if it's the best way to do it though. Never tried filtering java source code. /Anders On Tue, Jun 16, 2009 at 15:41, Paolo Castagna wrote: > Hi, > the "Introduction to the Build Lifecycle" [1] documentation describes a > "process-sources" phase of the default lifecycle. > > The description says: "process-sources - process the source code, for > example to filter any values." > > This is exactly what I want to do (i.e. filter some values in my source > code before compiling it). > > Could you, please, point me to an example which shows how to do that in > practice? > > Thanks, > Paolo > > [1] > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference > > - > 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: Custom lifecycle. Changing the default resource plugin confiduration.
glad to hear the custom mojo solution is working for you Saludos Cordiales desde EEUU! 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 den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Tue, 16 Jun 2009 10:12:00 -0400 > Subject: Re: Custom lifecycle. Changing the default resource plugin > confiduration. > From: edov...@gmail.com > To: users@maven.apache.org > > Martin, > Using an archetype for this is a good workaround. I may actually make an > archetype for this kind of projects. > I ended up writing a mojo and binding it to the initialize phase. In this > mojo I change the output directory. This seems to work fine. > Muchas gracias por tu ayuda. > > Cheers. > > Erick. > > On Mon, Jun 15, 2009 at 5:49 PM, Martin Gainty wrote: > > > > > > > http://maven.apache.org/plugins/maven-archetype-plugin/examples/create-with-property-file.html > > > > create the archetype with included properties to create a catalog > > $ cat archetype.properties > > archetype.groupId=my.group.id > > archetype.artifactId=archetype-with-properties > > archetype.version=2.0 > > archetype.filteredExtensions=java > > archetype.languages=groovy > > an_additional_property=my specific value > > output-directory=/usr/erick/theme > > //create archetype > > $ cd some-project > > $ mvn archetype:create-from-project > > -Darchetype.properties=../archetype.properties > > > > //install the archetype > > $ cd target/generated-sources/archetype/ > > $ mvn install > > //run it > > $ mvn archetype:generate -DarchetypeCatalog=local > > Ayuda? > > > > 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 den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > > destinataire prévu, nous te demandons avec bonté que pour satisfaire > > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > > de ceci est interdite. Ce message sert à l'information seulement et n'aura > > pas n'importe quel effet légalement obligatoire. Étant donné que les email > > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > > aucune responsabilité pour le contenu fourni. > > > > > > > > > > > Date: Mon, 15 Jun 2009 14:42:13 -0400 > > > Subject: Re: Custom lifecycle. Changing the default resource plugin > > confiduration. > > > From: edov...@gmail.com > > > To: users@maven.apache.org > > > > > > As a last resource solution yes. > > > The thing is I don't want to force the clients of the plugin to have to > > do > > > this. instead i just want them to declared an specific packaging type and > > > that's it. > > > Unfortunately they will have to still define the my theme plugin in their > > > poms.xml as it needs to have the extensions parameter set to true; but > > > forcing them to also define the resources plugin to change this > > particular > > > configuration parameter is plain wrong. > > > There most be another way of doing this that does not involve the clients > > of > > > the plugins doing anything special; that's what I am looking for. > > > > > > Gracias nuevamente. > > > > > > Erick. > > > > > > > > > On Mon, Jun 15, 2009 at 2:15 PM, Martin Gainty > > wrote: > > > > > > > > > > > de nada > > > > > > > > can you use a configuration parameter for output-directory? > > > > > > > > sample.plugin > > > > maven-erick-plugin > > > > 1.0 > > > > > > > >theme > > > > > > > > > > > > > > http://maven.apache.org/guides/plugin/guide-java-plugin-development.html > > > > > > > > Quizas? > > > > Martin > > > > __
Re: Custom lifecycle. Changing the default resource plugin confiduration.
Martin, Using an archetype for this is a good workaround. I may actually make an archetype for this kind of projects. I ended up writing a mojo and binding it to the initialize phase. In this mojo I change the output directory. This seems to work fine. Muchas gracias por tu ayuda. Cheers. Erick. On Mon, Jun 15, 2009 at 5:49 PM, Martin Gainty wrote: > > > http://maven.apache.org/plugins/maven-archetype-plugin/examples/create-with-property-file.html > > create the archetype with included properties to create a catalog > $ cat archetype.properties > archetype.groupId=my.group.id > archetype.artifactId=archetype-with-properties > archetype.version=2.0 > archetype.filteredExtensions=java > archetype.languages=groovy > an_additional_property=my specific value > output-directory=/usr/erick/theme > //create archetype > $ cd some-project > $ mvn archetype:create-from-project > -Darchetype.properties=../archetype.properties > > //install the archetype > $ cd target/generated-sources/archetype/ > $ mvn install > //run it > $ mvn archetype:generate -DarchetypeCatalog=local > Ayuda? > > 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 den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > de ceci est interdite. Ce message sert à l'information seulement et n'aura > pas n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > > > Date: Mon, 15 Jun 2009 14:42:13 -0400 > > Subject: Re: Custom lifecycle. Changing the default resource plugin > confiduration. > > From: edov...@gmail.com > > To: users@maven.apache.org > > > > As a last resource solution yes. > > The thing is I don't want to force the clients of the plugin to have to > do > > this. instead i just want them to declared an specific packaging type and > > that's it. > > Unfortunately they will have to still define the my theme plugin in their > > poms.xml as it needs to have the extensions parameter set to true; but > > forcing them to also define the resources plugin to change this > particular > > configuration parameter is plain wrong. > > There most be another way of doing this that does not involve the clients > of > > the plugins doing anything special; that's what I am looking for. > > > > Gracias nuevamente. > > > > Erick. > > > > > > On Mon, Jun 15, 2009 at 2:15 PM, Martin Gainty > wrote: > > > > > > > > de nada > > > > > > can you use a configuration parameter for output-directory? > > > > > > sample.plugin > > > maven-erick-plugin > > > 1.0 > > > > > >theme > > > > > > > > > > http://maven.apache.org/guides/plugin/guide-java-plugin-development.html > > > > > > Quizas? > > > Martin > > > __ > > > 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 den Inhalt uebernehmen. > > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas > le > > > destinataire prévu, nous te demandons avec bonté que pour satisfaire > > > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la > copie > > > de ceci est interdite. Ce message sert à l'information seulement et > n'aura > > > pas n'importe quel effet légalement obligatoire. Étant donné que les > email > > > peuvent facilement être sujets à la manipulation, nous ne pouvons > accepter > > > aucune responsabilité pour le contenu fourni. > > > > > > > > > > > > > > > > Date: Mon, 15 Jun 2009 13:50:32 -0400 > > > > Subject: Re: Custom lifecycle. Changing the default resource plugin > > > confiduration. > > > > From: edov...@gmail.com > > > > To: users@maven.apache.org > > > > > > > > *Martin, > > > > I don't think that will work here as maven it self is the one calling > the > > > > copy-resources goal on the resources-plugin. What I need is a > d
RE: Excluding files/webapp folder from a war
http://jira.codehaus.org/browse/MWAR-198 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 den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Tue, 16 Jun 2009 05:07:42 -0700 > From: fdur...@ticino.com > To: users@maven.apache.org > Subject: Re: Excluding files/webapp folder from a war > > > exactly, I'm trying to find a way or an example how to configure it, and the > doc you posted...I've seen it and went over it several times trying > different combinations, but it ain't working out. > > > without touching at the plugin, but just setting the packaging to war the > files that mvn puts in the target are different...(with a jar it doesn't > pack all those help, images,...folders) > > so I tryed configuring as written on the doc, but if I write: > > > src/main > > webapp > > > > > it adds even more folders and it doesn't exclude anything > > with: > > > > webapp > > > > > > it raises a nullpointer at packaging. > > > > > > > > rynam0 wrote: > > > > It sounds to me like you want to configure the maven-war-plugin with > > some excludes. Docs can be found here: > > > > http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html > > > > -- > View this message in context: > http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24052974.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 > _ Bing™ brings you maps, menus, and reviews organized in one place. Try it now. http://www.bing.com/search?q=restaurants&form=MLOGEN&publ=WLHMTAG&crea=TEXT_MLOGEN_Core_tagline_local_1x1
Surefire 2.4.3 and POJC
I have gone through the ClassLoader documentation at the surefire site couple of times, but cannot understand what combination of forkMode, useSystemClassLoader and manifestJarOnly surefire plugin configuration will give me a POJC (plain old java classpath). (I understand forkMode *cannot* be none for POJC) Thanks in advance. Thanks, mohan kr
Can I prevent maven from searching dependencies in localRepository?
Hi, I'm in trouble because of mavens localRepository. I know Maven installs everything into localRepository in install-phase, so I use the deploy-phase for bringing group-specific artifacts into group-specific repositories. Artifacts from other groups should only be usable as a dependency in the pom.xml, if they are deployed into another repository, lets call it „S“ (for share). So far so good ... In settings.xml I defined several profiles, so that every group gets it's own repository and S. My problem is, that maven finds everything in localRepository. Is there any possibility to tell maven not to look into localRepository, for searching dependencies? Thanks. Benjamin -- View this message in context: http://www.nabble.com/Can-I-prevent-maven-from-searching-dependencies-in-localRepository--tp24054742p24054742.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
process-sources: process the source code, for example to filter any values.
Hi, the "Introduction to the Build Lifecycle" [1] documentation describes a "process-sources" phase of the default lifecycle. The description says: "process-sources - process the source code, for example to filter any values." This is exactly what I want to do (i.e. filter some values in my source code before compiling it). Could you, please, point me to an example which shows how to do that in practice? Thanks, Paolo [1] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding files/webapp folder from a war
rynam0 wrote: > > Try something like this? > > > > src/main/webapp/someExcludedDirectory/** > > I removed the "war at the beginning of the pom, and tried with "mvn package war:war" (so it packages a jar and a war...) I just tried this: src/main/webapp/help/** nothing changes with src/main **/webapp/ **/help/ webapp same story...it just avoid to put a webapp and java directory in the war, but the help,static,style,...are still there basically I'd like the war to have the same contents as the jar (pretty much...) -- View this message in context: http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24053693.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
Re: Excluding files/webapp folder from a war
Try something like this? src/main/webapp/someExcludedDirectory/** On Tue, Jun 16, 2009 at 8:07 AM, turbo-555 wrote: > > exactly, I'm trying to find a way or an example how to configure it, and > the > doc you posted...I've seen it and went over it several times trying > different combinations, but it ain't working out. > > > without touching at the plugin, but just setting the packaging to war the > files that mvn puts in the target are different...(with a jar it doesn't > pack all those help, images,...folders) > > so I tryed configuring as written on the doc, but if I write: > > >src/main > > webapp > > > > > it adds even more folders and it doesn't exclude anything > > with: > > > > webapp > > > > > > it raises a nullpointer at packaging. > > > > > > > > rynam0 wrote: > > > > It sounds to me like you want to configure the maven-war-plugin with > > some excludes. Docs can be found here: > > > > > http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html > > > > -- > View this message in context: > http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24052974.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 > > -- �...@n
Re: How to apply the profile, defined in the profiles.xml in the parent project directory, to sub-modules?
There is a Jira ticket for this problem, which I provided a patch for quite a while ago. http://jira.codehaus.org/browse/MRELEASE-415 It'd be nice if the issue could get some attention by the developers. Reinhard Eugeny N Dzhurinsky schrieb: Hello there! I am facing some strange problem with the profile definition. Looks like if there is the file profiles.xml, located in the same directory as the pom.xml for the parent project - specifying one of the profiles with -P switch does not affect child modules. At least mvn help:active-profiles -Puser does show the desired profile in the active profiles list, but it does not show the desired profile as the active profile for submodules: = [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] profileIssue [INFO] module1 [INFO] module2 [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building profileIssue [INFO]task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'test:profileIssue:pom:1.0-SNAPSHOT': The following profiles are active: - user (source: profiles.xml) Active Profiles for Project 'test:module1:jar:1.0-SNAPSHOT': There are no active profiles. Active Profiles for Project 'test:module2:jar:1.0-SNAPSHOT': There are no active profiles. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue Jun 16 11:47:33 EEST 2009 [INFO] Final Memory: 5M/11M [INFO] = the effective pom does not contain properties, defined in the profiles.xml, for the sub-modules as well. So looks like it is not possible to configure the set of shared properties to be used by all modules in the multi-module project? Or may be there is some another way of doing this? Thank you in advance! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding files/webapp folder from a war
exactly, I'm trying to find a way or an example how to configure it, and the doc you posted...I've seen it and went over it several times trying different combinations, but it ain't working out. without touching at the plugin, but just setting the packaging to war the files that mvn puts in the target are different...(with a jar it doesn't pack all those help, images,...folders) so I tryed configuring as written on the doc, but if I write: src/main webapp it adds even more folders and it doesn't exclude anything with: webapp it raises a nullpointer at packaging. rynam0 wrote: > > It sounds to me like you want to configure the maven-war-plugin with > some excludes. Docs can be found here: > > http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html > -- View this message in context: http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24052974.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
Re: Excluding files/webapp folder from a war
It sounds to me like you want to configure the maven-war-plugin with some excludes. Docs can be found here: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html On 6/16/09, turbo-555 wrote: > > Hi all, > > I tried using the search, but I haven't found anything that could help me. > > I'm building a war package: > war.. > > but I need to keep out of the war the static part of the project, that would > be the whole webapp folder... > the structure of my project: > src: > -main: > -java > -resources > -webapp: > -help > -images > -static > -style > -WEB-INF > > > If I run mvn package I get a war with in it: > -help > -images > -static > -style > -... > > > is there a possibility to have mvn exclude these files? > I tried using the war plugin, but I must have missed something... > > > thanks > > -- > View this message in context: > http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24050485.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 > > -- Sent from my mobile device �...@n - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-eclipse-plugin]: MECLIPSE-548 requires attention
We asked several times to test the 2.7-SNAPSHOT before the release and we had no feedback about this issue which wasn't solved. Thus I don't know if it impacts so many projects.We'll try to fix it in 2.8, but I don't know in how many weeks/monthes, we'll be able to do it Cheers Cheers, Arnaud # Arnaud Héritier # http://blog.aheritier.net On Tue, Jun 16, 2009 at 8:08 AM, Ben Caradoc-Davies wrote: > MECLIPSE-548 is a showstopper for many projects that would otherwise use > maven-eclipse-plugin. I suspect many projects using the plugin are now > pinned to 2.5. This issue is marked as Critical priority, has six votes > and four watchers. Can anyone take at look at this issue? If you do not > intend to address this issue, or cannot address it at this time, please > comment on it to explain the situation. > > Kind regards, > Ben. > > > Original Message > Subject: [jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be > reverted. Classpath container entries should come before 3rd party jars > in .classpath > Date: Tue, 16 Jun 2009 01:25:42 +0800 > From: Joe Freeman (JIRA) > To: Caradoc-Davies, Ben (E&M, Kensington) > > >[ > > http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=180352#action_180352 > ] > > Joe Freeman commented on MECLIPSE-548: > -- > > How many votes does this have to have before it makes a release. > Version 2.7 just came out and it still has the same incorrect classpath > ordering for the JDK/JRE :-( > > MECLIPSE-442 should be reverted. Classpath container entries should come >> before 3rd party jars in .classpath >> >> >> >>Key: MECLIPSE-548 >>URL: http://jira.codehaus.org/browse/MECLIPSE-548 >>Project: Maven 2.x Eclipse Plugin >> Issue Type: Bug >> Components: Core : Dependencies resolution and build path >> (.classpath) >> Affects Versions: 2.6 >>Environment: all >> Reporter: Joe Freeman >> Priority: Critical >> >> A patch was accepted into maven 2.6 as part of jira MECLIPSE-442 >> that configures eclipse to compile with a different order than the jre will >> load with. This patch moved the container classpaths to the end of the >> classpath in eclipse. This behavior is incorrect. The JRE's jar files >> should come before any 3rd party libraries on the classpath because those >> classes will be loaded before any of the 3rd party jars and because the >> JRE's classes cannot be overridden by classes in a 3rd party jar. I >> understand why MECLIPSE-442 wanted to reverse the order so they could pick >> up the properties files. The best way to do this was to create properties >> files in the indvidual projects if he needed at run time or in the >> test/resources directory if it was only needed for unit testing. project >> resources come before everything in eclipse >> With this patch added to maven 2.6, we have a situation where eclipse >> tells us we have compiler error when maven command line compilations do not. >> >> > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > -- > Ben Caradoc-Davies > Software Engineer, CSIRO Exploration and Mining > Australian Resources Research Centre > 26 Dick Perry Ave, Kensington WA 6151, Australia > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Why is version 2.0 NOT same as 2.0.0?
On Tue, Jun 16, 2009 at 09:15, Paul Benedict wrote:
> It may seem strange that 2.0.0 is not the same as 2.0, but it's not
> totally unstrange. It is a matter of precision.
>
> Did you know BigDecimal("2.00") does not equal BigDecimal("2.0")?
>
> The second situation can be rectified by a setting. Perhaps the first
> (in Maven) should too.
>
> Paul
I don't think this line of arguments applies here. **versions are not
floating point numbers!**
A version is generally treated as a tuple of integers, which are then
lexicographically compared. That is:
"2.0" -> (2, 0)
"2.0.0" -> (2, 0, 0)
"2.13.34" -> (2, 13, 34)
But the real world is messy, which raises questions:
(1) Does the tuple of integers have some maximal length ("precision")
or is it effectively unbounded.
-> in Maven's case it's bounded at length 3. [[I wish it were unbounded]]
(2) How do we treat the "missing" places when comparing two tuples of
differing length?
-> Maven treats these places as 0 (zero) when comparing artifact versions.
(2, 0) == (2, 0, 0)
Otherwise, a normal lexicographical sort would yield: (2, 0) < (2, 0,
0), just as "park" < "parka".
(3) Do we allow non-numeric parts in the version?
-> Maven does allow a qualifier which is effectively compared as a
string. (Followed by a dash and build number, except this is broken
according to the docs and is parsed as part of the qualifier.)
Effectively, it is as if maven sorts "2.0-qualifier" as if it were the
tuple (2, 0, 0, "qualifier").
2.0-qualifier -> ( (2, 0), "qualifier" ) -> (2, 0, 0, "qualifier")
(4) How do we handle versions that don't have the expected syntax?
-> Maven punts and considers such versions to be either always greater
or always lesser than parseable versions. (I don't recall which). [[I
wish Maven had chosen to be "opinionated" about the format of version
numbers and mandated that they all be parseable. It is, after all,
opinionated about a great many other things and sanity in versioning
would seem be to central to the whole resolution magic it tries to
do.]]
// Ben
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Controling workflow an a global level
Hi Oskar! I use the same scheme as your second scenario and in MY_SYSTEM_GLOBAL (inherits global) I have section with all the plugins configured for jar, ejb, war, ear packaging types plus specialities done by was6 plugin and of course all the stack of checkstyle, pmd, findbugs, cobertura for Hudson CI. Then I have my PROJECT specific level which inherits MY_SYSTEM_GLOBAL mentioned earlier and of course here I have listed my sub modules. Then finally in my ejb, ear, etc. submodules I declare the necessary plugins inside a block. For example, for an ejb module which uses XDoclet and I also generate wsEjbdeploy stuff with was6 plugin, I have a list of plugin declarations like the following: org.codehaus.mojo xdoclet-maven-plugin org.codehaus.mojo was6-maven-plugin org.apache.maven.plugins maven-ejb-plugin But if you really would like to throw all these declarations on a common place and have only very simple pom.xml-s, then you have the possibility to create packaging specific common modules. At the end your EJB implementation module would inherit the corresponding common POM. The ideea is that in a project consisting from many types of submodules, its enough to have an entry point, where there you specify your submodules by tag, but your submodules does not need to point back to the top module of your project structure by defining as parent module. Instead your submodules would use as the parent module, the EJB specific POM.xml and so forth. Regards, Tibor On Tue, Jun 16, 2009 at 11:17 AM, Oskar Carlstedt wrote: > > Hello all! > > I've been using Maven since a long time. But still I haven't found an > answer > of how to control the workflow on a global level while still having the > opportunity to override confiuration on a system basis. What I want to do > is > to configure plugins in a company global pom-file just to make it easier > for > other projects to use our build concept - but still I don't want it to be a > requirement to use the global pom as a parent. > > In a huge system with about 50 subprojects we may have som simple > jar-projects, some ejb-projects, some war-projects etc., etc. It would be > great to be able to configure the build process for all these projects > types > in one or several company global files. But the implementataions of these > files still want to use some project specific configurations. > > Doing this we might end up with > > > > > GLOBAL > > GLOBAL_JAR (enherits global) GLOBAL_EJB (inherits global) > > MY_SYSTEM_GLOBAL (inherits ?) > > MY_SYSTEM_JAR_IMPL (inherits GLOBAL_JAR), MY_SYSTEM_EJB_IMPL (inherits > GLOBAL_EJB) > > > -- > > Doing this way makes i possible to control the build process/build flow. On > the other hand it is impossible to add global overriding configuration from > my system, except for properties in a settings.xml. So this is not an > optimal solution. > > Doing the other way having one global pom where I can put global > configuration s.a. reporting, properties etc. This concpet won't make it > possible to control the build flow, but it give a relative huge amount of > freedom for each project. > > > > > GLOBAL > > MY_SYSTEM_GLOBAL (inherits global) > > MY_SYSTEM_JAR_IMPL (inherits MY_SYSTEM_GLOBAL), MY_SYSTEM_EJB_IMPL > (inherits > MY_SYSTEM_GLOBAL) > > > -- > > > So, do you have any ideas about any good solution where I can control the > build process on a company basis, override it on a system basis and finally > make it possible to reconfigure everyting in each single project but still > take part of system specific properties/configurations. > > > Best regards > Oskar > > -- > View this message in context: > http://www.nabble.com/Controling-workflow-an-a-global-level-tp24050579p24050579.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 > >
release plugin?
Hi all, Why if I specify exactly what versions to use for release and developement version for the exact module and specify the default values does the release plugin still try (and fail) to parse the versions? e.g. mvn.bat -B -X -e -Dproject.dev.test:test=X_1.0.1-SNAPSHOT -Dproject.rel.test:test=X_1.0.0 -DdevelopmentVersion=BOGUS -DreleaseVersion=BOGUS release:prepare (this is a single module project groupID=test artifactId=test) Apache Maven 2.1.0 (r755702; 2009-03-18 19:10:27+) Java version: 1.6.0_06 maven-release-plugin:2.0-beta-9 [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error parsing version, cannot determine next version: Unable to parse the version string: "X1.0.0-SNAPSHOT" at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:703) ... Caused by: org.apache.maven.plugin.MojoExecutionException: Error parsing version, cannot determine next version: Unable to parse the version string: "X1.0.0-SNAPSHOT" at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRelea seMojo.java:186) ... Caused by: org.apache.maven.shared.release.ReleaseExecutionException: Error parsing version, cannot determine next versi on: Unable to parse the version string: "X1.0.0-SNAPSHOT" at org.apache.maven.shared.release.phase.MapVersionsPhase.getNextVersion(Ma pVersionsPhase.java:227) at org.apache.maven.shared.release.phase.MapVersionsPhase.execute(MapVersio nsPhase.java:140) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultRel easeManager.java:196) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultRel easeManager.java:133) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultRel easeManager.java:96) at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareRelea seMojo.java:182) ... 18 more Caused by: org.apache.maven.shared.release.versions.VersionParseException: Unable to parse the version string: "X1.0.0-SNAPSHOT" at org.apache.maven.shared.release.versions.DefaultVersionInfo.(Defau ltVersionInfo.java:171) at org.apache.maven.shared.release.phase.MapVersionsPhase.getNextVersion(Ma pVersionsPhase.java:177) ... 23 more Fair enoguh if I haven't parsed in any versions as this version is in effect just a string qualifier (which is a valid version?) - but I have been explicit so what gives ? Would this be considered as a bug or would it be rejected due to the non-standard version. Regards, /James ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **
Controling workflow an a global level
Hello all! I've been using Maven since a long time. But still I haven't found an answer of how to control the workflow on a global level while still having the opportunity to override confiuration on a system basis. What I want to do is to configure plugins in a company global pom-file just to make it easier for other projects to use our build concept - but still I don't want it to be a requirement to use the global pom as a parent. In a huge system with about 50 subprojects we may have som simple jar-projects, some ejb-projects, some war-projects etc., etc. It would be great to be able to configure the build process for all these projects types in one or several company global files. But the implementataions of these files still want to use some project specific configurations. Doing this we might end up with GLOBAL GLOBAL_JAR (enherits global) GLOBAL_EJB (inherits global) MY_SYSTEM_GLOBAL (inherits ?) MY_SYSTEM_JAR_IMPL (inherits GLOBAL_JAR), MY_SYSTEM_EJB_IMPL (inherits GLOBAL_EJB) -- Doing this way makes i possible to control the build process/build flow. On the other hand it is impossible to add global overriding configuration from my system, except for properties in a settings.xml. So this is not an optimal solution. Doing the other way having one global pom where I can put global configuration s.a. reporting, properties etc. This concpet won't make it possible to control the build flow, but it give a relative huge amount of freedom for each project. GLOBAL MY_SYSTEM_GLOBAL (inherits global) MY_SYSTEM_JAR_IMPL (inherits MY_SYSTEM_GLOBAL), MY_SYSTEM_EJB_IMPL (inherits MY_SYSTEM_GLOBAL) -- So, do you have any ideas about any good solution where I can control the build process on a company basis, override it on a system basis and finally make it possible to reconfigure everyting in each single project but still take part of system specific properties/configurations. Best regards Oskar -- View this message in context: http://www.nabble.com/Controling-workflow-an-a-global-level-tp24050579p24050579.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
Excluding files/webapp folder from a war
Hi all, I tried using the search, but I haven't found anything that could help me. I'm building a war package: war.. but I need to keep out of the war the static part of the project, that would be the whole webapp folder... the structure of my project: src: -main: -java -resources -webapp: -help -images -static -style -WEB-INF If I run mvn package I get a war with in it: -help -images -static -style -... is there a possibility to have mvn exclude these files? I tried using the war plugin, but I must have missed something... thanks -- View this message in context: http://www.nabble.com/Excluding-files-webapp-folder-from-a-war-tp24050485p24050485.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
Help to use new version of dependency on other repos server
Hi, My project is using maven 2. In our master pom.xml we have defined a repository that hosts all our dependencies, jars ( i hope I get all the terminology right here...). What happened was that we got a new version 1.0.1 of a dependency ( jar) and it is hosted on: http://nlryx106.etm.ericsson.se:8081/artifactory/product-ngin-deliveries The older version 1.0.0 was hosted on our internal repos but I don't know how to put the files in their repos on the server. And since I only want to see if I can compile with the new version I want to do as little as possible ( don't we all). What do I change in the master pom.xml to give it a try with this new version 1.0.1 on the other repos ( the url given above). Br, //mike = Ericsson AB Mikael Petterson Software Designer Mobile: +46-(0)70-2673044 Email: mikael.petter...@ericsson.com =
How to apply the profile, defined in the profiles.xml in the parent project directory, to sub-modules?
Hello there! I am facing some strange problem with the profile definition. Looks like if there is the file profiles.xml, located in the same directory as the pom.xml for the parent project - specifying one of the profiles with -P switch does not affect child modules. At least mvn help:active-profiles -Puser does show the desired profile in the active profiles list, but it does not show the desired profile as the active profile for submodules: = [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] profileIssue [INFO] module1 [INFO] module2 [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building profileIssue [INFO]task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'test:profileIssue:pom:1.0-SNAPSHOT': The following profiles are active: - user (source: profiles.xml) Active Profiles for Project 'test:module1:jar:1.0-SNAPSHOT': There are no active profiles. Active Profiles for Project 'test:module2:jar:1.0-SNAPSHOT': There are no active profiles. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue Jun 16 11:47:33 EEST 2009 [INFO] Final Memory: 5M/11M [INFO] = the effective pom does not contain properties, defined in the profiles.xml, for the sub-modules as well. So looks like it is not possible to configure the set of shared properties to be used by all modules in the multi-module project? Or may be there is some another way of doing this? Thank you in advance! -- Eugene N Dzhurinsky pgpUwM56bwr37.pgp Description: PGP signature
plugin development - map properties
Hello! Is it possible, that the value-elements of a map-property, are Objects, not only Strings? I tried the scenario described below, but the value Elements of the MAP are always null... My context: I have a property with the Type ToolChain: ... /** * @optional * @parameter */ private ToolChain toolChain; ... The toolChain class has a Map with key-elements as String and the Value-Elements should be objects of self defined Type ChainLink: /** * Injected from the POM of the project, if this option is used! */ private Map chainLinks = null; The configuration of the plugin in the pom looks like that: text All classes are in the same packages as the mojo! The result is, that the chainLinks-Map is injected, but only the key-elements are filled. The vlaues are always null. thanks, if you have read to this point ;-) Is my approach wrong? Or is this not possible dave
Re: maven-dependency-plugin doesn't find all dependencies in several repositories
gorgophol wrote: > > Is it possible that the dependency-plugin uses information from > localRepository instead of Repos 1 and 2? > > I recognized the following behavior: > > Every time I install an artifact into Repos 2 using deploy:file, the jar > and the pom.xml are installed into correctly into Repos 2 (with all the > correct dependency-entries in the pom.xml). but also the pom.xml of the > artifact in my localRepository is replaced with a new one, containing no > dependecies ... > I solved the problem by using the pomFile-parameter for the deploy-plugin. Now a correct version of the pom.xml is stored in localRepository and so dependency-plugin seems to locate all dependencies. Thanks a lot for your time and hints, which took me to the real reason of the problem. Now work is a lot more fun again :-) -- View this message in context: http://www.nabble.com/maven-dependency-plugin-doesn%27t-find-all-dependencies-in-several-repositories-tp23961970p24049425.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
Re: [ANNOUNCEMENT] - UNIX Maven Plugin 1.0-alpha-4 released
I think a much better name would be the Unix Packaging Maven Plugin. Sorry, but without an adjective, it doesn't clearly say what the plugin does. 2009/6/15 Trygve Laugstøl : > I'm happy to announce the fourth alpha release of unix-maven-plugin. > This is still primarily a technology preview, but is fully functional. > > = New in this release = > > o support for creating "zip" archives > o added support for classes for pkg > o %doc and %config for RPM > o Lots of documentation, including a PDF. > > == Technical changes == > > MUNIX-18: Simplify the script mechanism > MUNIX-17: Document how versions and revisions are calculated > MUNIX-16: Document how the scripts directories work > MUNIX-15: Improve error message when an artifact is not found > MUNIX-12: Add support for creating zip files > MUNIX-6: set-attributes doesn't pick up paths that aren't explicitly > created with mkdirs (Filed by Marius Gravdal > MUNIX-4: Add support for the %doc directive for RPM (filed by Erik > Drolshammer) > MUNIX-3: Add support for the %config directive for RPM (filed by Erik > Drolshammer) > MUNIX-1: the "release" portion of the rpm does not have to be an int > (filed by Brett Okken) > > = About the plugin = > > The unix-maven-plugin is a Maven plugin for producing installation > packages for UNIX platforms. > > The current release is 1.0-alpha-4. This release is meant as a > technology preview release. The plugin is useful but work is in progress > to make sure it support even more use cases. > > The plugin has gained a substantial amount of documentation, available > at [1]. > > The plugin combines the work of the deb, solaris and rpm Maven plugins > and also handles the aspect of assembling the packages without using the > assembly plugin. > > Supported platforms: > > * Debian (.deb) > * RedHat and Fedora (.rpm) > * SysV packages for Solaris (.pkg) > * Generic Zip files (.zip) > > The development happens on the Codehaus Mojo project [2], if you want to > try it out, have found an issue or just want your use case supported get > in touch through the mailing lists [3]. > > [1]: http://mojo.codehaus.org/unix/usage.html > [2]: http://mojo.codehaus.org/unix/ > [3]: http://mojo.codehaus.org/unix/mail-lists.html > > - > 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: Why is version 2.0 NOT same as 2.0.0?
It may seem strange that 2.0.0 is not the same as 2.0, but it's not
totally unstrange. It is a matter of precision.
Did you know BigDecimal("2.00") does not equal BigDecimal("2.0")?
The second situation can be rectified by a setting. Perhaps the first
(in Maven) should too.
Paul
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency version at pom level
On Mon, Jun 15, 2009 at 6:54 PM, tony k wrote: > the general use case is that you are working with a series of third-party > dependencies > (and their respective poms) that specify conflicting versions of a > particular > library commons-logging for example, and you want to force a specific > version > that you know you will be running with. let's say you want to verify > behavior > of those third party dependencies with this specific version using the test > goal. Perhaps I am misunderstanding your question, but I think the dependecyManagement section in fact does exactly what you want: enforce versions of dependencies. Specify the following section in a common parent for your artifacts, mvn install, and you should be done (I used version 1.1 for the sake of example): commons-logging commons-logging 1.1 ... You can visually test the result using 'mvn help:effective-pom' or 'mvn dependency:tree'. http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html "Dependency management - this allows project authors to directly specify the versions of artifacts to be used when they are encountered in transitive dependencies or in dependencies where no version has been specified. ... A can include D as a dependency in its dependencyManagement section and directly control which version of D is used when, or if, it is ever referenced." Controlling versions through dependencyManagement is a good idea (combined with parent POMs, dare I say a "best practice"). Handling this stuff is one of maven's key strengths; it was designed for this general use case. No surprise that this is "one of the first things" you asked yourself :) You would only *need* to use exclusions if you didn't want the dependency at all. If that were true, then yes, I think you would have to do it for each artifact that specified it as a direct dependency. Zac - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
