error when running mvn site:deploy
Hello, I have error below when running mvn site:deploy. My maxs number of files seems to have appropriate values cat /proc/sys/fs/file-nr 35840 20 What could be the problem? [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Failed to upload to remote repository: /maven2/internal/site/axs/axs-root-pom/axs-core-root-pom/axs-ssh-adapter/./images/icon_sortright.gif : /var/axs/buildsite/basic.app/container/axs-ssh-adapter/target/site/images/icon_sortright.gif (Too many open files) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:203) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) ... 16 more Caused by: org.apache.maven.wagon.TransferFailedException: Failed to upload to remote repository: /maven2/internal/site/axs/axs-root-pom/axs-core-root-pom/axs-ssh-adapter/./images/icon_sortright.gif : /var/axs/buildsite/basic.app/container/axs-ssh-adapter/target/site/images/icon_sortright.gif (Too many open files) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:558) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:546) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:187) ... 18 more Caused by: java.io.FileNotFoundException: /var/axs/buildsite/basic.app/container/axs-ssh-adapter/target/site/images/icon_sortright.gif (Too many open files) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at org.apache.webdav.lib.WebdavResource.putMethod(WebdavResource.java:2790) at org.apache.maven.wagon.providers.webdav.WebDavWagon.putDirectory(WebDavWagon.java:554) ... 20 more [INFO] - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Custom lifecycles and getting parameters to them
Hi, For sample purposes, I've defined a custom lifecycle as follows: project-archetypes-lifecycle validate org.apache.maven.plugins:maven-archetype-plugin:generate fred bob false And in my Maven plug-in, I've included an annotation to execute the lifecycle before my mojo executes: * @execute lifecycle="project-archetypes-lifecycle" phase="validate" But when I run my plug-in, I get the following error: [WARNING] Property artifactId is missing. Add -DartifactId=someValue It'll only work if I pass -DartifactId to my mojo from the command line. It seems that configuration element in the lifecycle definition is ignored for artifactId. But yet, the interfaceMode=false seems to work. Any ideas how I can pass variable data into the custom lifecycle definition when I invoke it from another mojo? Thanks, Brad The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: Maven ear plugin -- add files into META-INF folder
Hi Markku,
Thanks a lot.
Previously my problem lie in that I missed the META-INF subdirectory under
"earSourceDirectory".
Best Regards,
Thunder
On Wed, Mar 17, 2010 at 12:37 AM, Markku Saarela wrote:
> You could use
> ${project.build.outputDirectory}
> and use normal build resources
>
>
>
> src/main/resources
> true
>
>
>
> and put this weblogic file in subdirectory META-INF also you can define
> additional resource directories there.. This way you can also filter these
> files.
>
> rgds,
>
> Markku
>
>
> On 16.3.2010 8:16, Thunder Farmer wrote:
>
>> Thanks.
>>
>> I do look into the "earSourcesDirectory" parameter.
>> The problem is that files specified by "earSourcesDirectory " will be
>> under
>> root directory of the ear, rather than under ear/META-INF.
>> Any idea for my issue?
>>
>> I just want some files out of default folder
>> "src\main\application\META-INF"
>> to be parckaged into ear/META-INF/
>>
>> Thanks,
>> Thunder
>>
>> On Tue, Mar 16, 2010 at 1:18 PM, Markku Saarela> >wrote:
>>
>>
>>
>>> Hi,
>>>
>>> As in
>>>
>>> http://maven.apache.org/plugins/maven-ear-plugin/examples/filtering-sources.htmlnoteduse
>>> earSourcesDirectory.
>>>
>>>
>>> Rgds,
>>>
>>> Markku
>>>
>>>
>>> On 16.3.2010 5:06, Thunder Farmer wrote:
>>>
>>>
>>>
Dear all,
During ear packaging, is there any way to add my personal files into the
ear/META-INF folder if I don't put it in the default source folder
"src\main\application\META-INF".
For example, I have weblogic specific file "weblogic-application.xml",
it
dost't lie in the default folder "src\main\application\META-INF", what
could
I do in this case?
I am using maven 2.1.0-M1.
any idea would be appreciated.
Thanks,
Thunder
>>>
>>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Listen to Your Heart
Follow Your Heart
Re: jetty:plugin does not start during verify phase
yes. you need to rethink your testing... perhaps the client module is actually a test scoped dep of your war (assuming it is not a current dep of your war) in which case you run the tests in the war module Sent from my [rhymes with tryPod] ;-) On 16 Mar 2010, at 17:59, Filippo De Luca wrote: Hi maven users, I have a multimodule project with one war module and a jar module. The jar module is a client for the war module. The server pom contains: org.mortbay.jetty maven-jetty-plugin 10 /xxx-service stop 8009 start-jetty pre-integration-test run-exploded 0 true stop-jetty post-integration-test stop The client pom contains: org.codehaus.mojo failsafe-maven-plugin integration-test integration-test verify verify When I invoke mvn integration-test on the parent project, the tests finished succesfully, while if i invoke mvn verify, the test filed because jetty has been stopped before the client tests are invoked. Is it my error? -- Filippo De Luca -- Email: dl.fili...@filosganga.it Web: http://www.filosganga.it LinkedIn: http://www.linkedin.com/in/filippodeluca mobile: +393395822588 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Sonar 2.0 released
The Sonar Team is pleased to announce the release of Sonar 2.0. The main feature of Sonar 2.0 consists in analysis of Design & Architecture and object-oriented metrics. This new version enables to easily : * remove cycles between packages by cutting undesired dependencies * represent and navigate across dependencies between components * hunt for classes having for instance too many responsibilities On top of this, it contains 45 other improvements and bug-fixes [1]. To enjoy the new version, you can download it [2] straight away. - The Sonar team Links [1] Release notes : http://sonar.codehaus.org/downloads/#2.0 [2] Download : http://sonar.codehaus.org/downloads -- View this message in context: http://old.nabble.com/-ANN--Sonar-2.0-released-tp27924242p27924242.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 with sourceforge
Has anyone gotten the Maven release plugin to work on Windows with a CVS
SourceForge project. I've been working on this all day and have made some
progress but now I'm stuck. In my POM, I have my SCM defined as:
scm:cvs:ext:${cvs.userna...@ferris.cvs.sourceforge.net:/cvsroot/ferris:ferris-assemblies
HEAD
http://ferris.cvs.sourceforge.net/viewvc/ferris/ferris-assemblies
I've used puttygen.exe to create a key and I have SSH_RSH set to use
plink.exe.
Running cvs commands from the command line works fine.
I then start the release project with:
C:\>mvn -Dmaven.scm.provider.cvs.implementation=cvs_native release:prepare
This actually works OK until it gets to the point where the plugin wants to
checkin the new POM. When it gets to this point it failes with the following
error message:
[INFO] Checking in modified POMs...
>[INFO] Executing: cmd.exe /X /C "cvs -z3 -f -q commit -R -F
>C:\DOCUME~1\MICHAE~1.REM\LOCALS~1\Temp\scm-commit-
>message7879987862192973151.txt pom.xml"
>[INFO] Working directory: C:\Apps\Workspace\ferris-assemblies
>[INFO]
>[ERROR] BUILD FAILURE
>[INFO]
>[INFO] Unable to commit files
>Provider message:
>The cvs command failed.
>Command output:
>cvs [commit aborted]: the :extssh: access method is not available on this
>system
I can't figure out why it's trying to use extssh now?? Anyone have any ideas??
Thanks!
Mike
Re: compile from multiple source directories
Dan Tran writes:
>
>
>${basedir}/../../relative to your project
> directory
>
>
Well, that's better than nothing. I'm not thrilled about effectively
hard coding the location of the project this way.
> is there a reason why you want to do this way? can you just do multi
> modules build?
Not without facing the same requirement. There is a giant non-modular
source tree that I have no control over. I need to use some of the
source from that tree.
Kendall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
jetty:plugin does not start during verify phase
Hi maven users, I have a multimodule project with one war module and a jar module. The jar module is a client for the war module. The server pom contains: org.mortbay.jetty maven-jetty-plugin 10 /xxx-service stop 8009 start-jetty pre-integration-test run-exploded 0 true stop-jetty post-integration-test stop The client pom contains: org.codehaus.mojo failsafe-maven-plugin integration-test integration-test verify verify When I invoke mvn integration-test on the parent project, the tests finished succesfully, while if i invoke mvn verify, the test filed because jetty has been stopped before the client tests are invoked. Is it my error? -- Filippo De Luca -- Email: dl.fili...@filosganga.it Web: http://www.filosganga.it LinkedIn: http://www.linkedin.com/in/filippodeluca mobile: +393395822588
Re: New snapshots versus the local repo
On 16 March 2010 14:37, Benson Margulies wrote: > Just for fun, I think it's worth explaining the environment. > > We are relatively new adopters of Maven. Up until now, we've done > maven releases only for external product releases. Thus, there are > snapshot dependencies amongst our internal components for months on > end. To make my original scenario a trifle more concrete: > > I'm plugging away at a set of changes. The changes are across several > aggregated components. I finish with one component, and I'm working on > the next. > > The overall set isn't going to be done in a day, but they feel really > light for a branch. Meanwhile, one of my colleagues knocks off a small > fix in the component I've finished with. So, she checks in, hudson > builds, and produces a snapshot. Unless I go back and rebuild my copy > of that component, I get a surprise. > > Say that we tried to address this by making internal releases and only > using snapshot dependencies 'locally,' to a build tree. Is there a > plugin that will auto-edit a tree, finding all dependencies on g/a/v > x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back > for checkin? > > have a look at versions-maven-plu...@mojo might do some of what you want > My fantasy continues to be that I could put a filter in my > settings.xml that turned off snapshot updates on a set of g/a/v > patterns. > > > > > On Tue, Mar 16, 2010 at 9:00 AM, Maven User > wrote: > > You could probably do a dependency:resolve and leverage the > > includes/excludes - but that starts smelling hacky. > > > > I'm in agreement with the earlier comment. If you're allowing any/all > devs > > to deploy, it can't be a free-for-all. > > > > Why not let ci be the bottleneck (which implicitly has some degree of > > automated testing)? Devs have the option of deactivating tests > locally > > > > On Mar 16, 2010, at 8:52 AM, Stephen Connolly > > wrote: > > > >> I guess the issue is if you want to update some but not all of your > >> -SNAPSHOT dependencies. Maven does not provide filtering of update > >> checking > >> > >> On 16 March 2010 12:46, Maven User wrote: > >> > >>> Google maven updatepolicy - you (as a user) can choose how often (or at > >>> all) you take versions from a repository. > >>> > >>> > >>> On Mar 16, 2010, at 8:18 AM, Benson Margulies > >>> wrote: > >>> > >>> Well, at least now we can see the disconnect. People don't want to > > make a branch every time they are working on something for more than a > day. (Default snapshot update is a day.) Making a branch is fairly > tiresome, especially given the difficulty of persuading release:branch > to work. The 'person' who published the snapshot is hudson, just doing > its job. > > If the answer is, 'always make a branch,' then that's the answer. It > is not a popular answer with the developers I'm supporting. I wish > there was some alternative involving controlling snapshot updates per > g/a instead of per repository. --offline prevents unwanted updates, > but it also prevents wanted updates of other, unmodified, things, and > new dependencies. > > > On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly > wrote: > > > On 16 March 2010 04:25, Ron Wheeler > > wrote: > > > > Benson Margulies wrote: > >> > >> I have this feeling that I'm missing something terribly obvious. > >>> > >>> 1: grab a tree and make some changes. > >>> 2: mvn. Now you've got SNAPSHOT versions in your local repository > >>> 3: someone else checks in a change and runs mvn deploy. Now the > >>> snapshot repo has jars newer than the local repo. > >>> > >> > >> 4: run mvn and download those over top of the local mods. > >> > >>> > >>> > >> Only if you have the update rule for your snapshot repos set to > check > > > > every > > time. > > > > If you are working on a branch, then run maven in offline mode to > > prevent > > having to worry about picking up other versions that somebody elese > has > > deployed > > > > > > > >> Without patching all the version numbers, is there a best practice > or > >>> > >>> standard mechanism to stay out of this pickle? > >>> > >>> > >>> What is the pickle? You have the latest version which is what you > >>> want > >> > >> if > >> the person doing the deploy has done the deploy for a reason. > >> If the version deployed is not better than the version that you have > >> locally, you beat the crap out of the guy who deployed a version > when > >> they > >> shouldn't have. > >> > >> If people deploy crap into repositories, you will have a problem > >> eventually. > >> If you put your version into your source management, the other > person > >> would > >> have based his mods on yours or at least noticed the conflicts > befor
Re: generating multiple artifacts
> I have an ejb project for which I need to generate an EJB jar (bean and > interfaces) and a client jar (containing only the interfaces). I looked > into using assemblies but that seems better suited for I know its a huge hassle and very expensive to use Google, but try the phrase "maven plugin ejb client" and you'll find your answer posted in the Maven EJB Plugin documentation. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
taglibs with skinny war
I followed this example: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html So, I have all dependencies declared on the EAR and WARs now and the WARs are "skinny" But, there are some JARs that need to stay in the WARs (i.e. sitemesh) because they won't work unless they are under WEB-INF/lib (can't be in the EAR) I tried to use the packagingIncludes and packagingExcludes together, but it didn't work. For example, this did not work, how come? How can I get all JARs to go to the EAR, except sitemesh? WEB-INF/lib/sitemesh-2.4.1.jar WEB-INF/lib/*.jar true lib/
Re: maven-ejb-plugin & was6-maven-plugin generated jar files
> For me the above fix didn't help, it deployed ok, but the classes are not > included into the final jars. I fixed the above problem as shown below. I > guess the fix is only needed for WAS60, and probably only in certain cases. You should submit a Jira for this so it will be included in a future release of the maven-ejb-plugin! It looks like a reasonable contribution/patch especially if it solves the problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven ear plugin -- add files into META-INF folder
You could use
${project.build.outputDirectory} and
use normal build resources
src/main/resources
true
and put this weblogic file in subdirectory META-INF also you can define
additional resource directories there.. This way you can also filter
these files.
rgds,
Markku
On 16.3.2010 8:16, Thunder Farmer wrote:
Thanks.
I do look into the "earSourcesDirectory" parameter.
The problem is that files specified by "earSourcesDirectory " will be under
root directory of the ear, rather than under ear/META-INF.
Any idea for my issue?
I just want some files out of default folder "src\main\application\META-INF"
to be parckaged into ear/META-INF/
Thanks,
Thunder
On Tue, Mar 16, 2010 at 1:18 PM, Markku Saarelawrote:
Hi,
As in
http://maven.apache.org/plugins/maven-ear-plugin/examples/filtering-sources.htmlnoted
use earSourcesDirectory.
Rgds,
Markku
On 16.3.2010 5:06, Thunder Farmer wrote:
Dear all,
During ear packaging, is there any way to add my personal files into the
ear/META-INF folder if I don't put it in the default source folder
"src\main\application\META-INF".
For example, I have weblogic specific file "weblogic-application.xml", it
dost't lie in the default folder "src\main\application\META-INF", what
could
I do in this case?
I am using maven 2.1.0-M1.
any idea would be appreciated.
Thanks,
Thunder
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: New snapshots versus the local repo
> No tool is going to insulate you from bad human management practices. > If 2 people are writing the same software module, they have to work to the > same spec and coordinate themselves. Ron nailed it. Communication is key!! Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
generating multiple artifacts
I have an ejb project for which I need to generate an EJB jar (bean and interfaces) and a client jar (containing only the interfaces). I looked into using assemblies but that seems better suited for completely different filesets/modules. Can anyone shed some light on the right approach? Thanks -- View this message in context: http://n2.nabble.com/generating-multiple-artifacts-tp4744752p4744752.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: New snapshots versus the local repo
Disable automatic snapshot checking (this is the default in M3) and then you're fine. Nothing changes until you ask for updates. On Tue, Mar 16, 2010 at 11:32 AM, Benson Margulies wrote: > On Tue, Mar 16, 2010 at 11:18 AM, Maven User wrote: >> But then shouldn't you be building with what's available, not a snapshot >> created at some other time, > > At time 0, I build everything. Components a, b, c, d. At time 1, a new > snapshot arrives for component a, and unless i go back and run mvn > clean install on (a), it replaces my local build. > > >> >> >> >> On Mar 16, 2010, at 10:37 AM, Benson Margulies >> wrote: >> >>> Just for fun, I think it's worth explaining the environment. >>> >>> We are relatively new adopters of Maven. Up until now, we've done >>> maven releases only for external product releases. Thus, there are >>> snapshot dependencies amongst our internal components for months on >>> end. To make my original scenario a trifle more concrete: >>> >>> I'm plugging away at a set of changes. The changes are across several >>> aggregated components. I finish with one component, and I'm working on >>> the next. >>> >>> The overall set isn't going to be done in a day, but they feel really >>> light for a branch. Meanwhile, one of my colleagues knocks off a small >>> fix in the component I've finished with. So, she checks in, hudson >>> builds, and produces a snapshot. Unless I go back and rebuild my copy >>> of that component, I get a surprise. >>> >>> Say that we tried to address this by making internal releases and only >>> using snapshot dependencies 'locally,' to a build tree. Is there a >>> plugin that will auto-edit a tree, finding all dependencies on g/a/v >>> x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back >>> for checkin? >>> >>> My fantasy continues to be that I could put a filter in my >>> settings.xml that turned off snapshot updates on a set of g/a/v >>> patterns. >>> >>> >>> >>> >>> On Tue, Mar 16, 2010 at 9:00 AM, Maven User >>> wrote: You could probably do a dependency:resolve and leverage the includes/excludes - but that starts smelling hacky. I'm in agreement with the earlier comment. If you're allowing any/all devs to deploy, it can't be a free-for-all. Why not let ci be the bottleneck (which implicitly has some degree of automated testing)? Devs have the option of deactivating tests locally On Mar 16, 2010, at 8:52 AM, Stephen Connolly wrote: > I guess the issue is if you want to update some but not all of your > -SNAPSHOT dependencies. Maven does not provide filtering of update > checking > > On 16 March 2010 12:46, Maven User wrote: > >> Google maven updatepolicy - you (as a user) can choose how often (or at >> all) you take versions from a repository. >> >> >> On Mar 16, 2010, at 8:18 AM, Benson Margulies >> wrote: >> >> Well, at least now we can see the disconnect. People don't want to >>> >>> make a branch every time they are working on something for more than a >>> day. (Default snapshot update is a day.) Making a branch is fairly >>> tiresome, especially given the difficulty of persuading release:branch >>> to work. The 'person' who published the snapshot is hudson, just doing >>> its job. >>> >>> If the answer is, 'always make a branch,' then that's the answer. It >>> is not a popular answer with the developers I'm supporting. I wish >>> there was some alternative involving controlling snapshot updates per >>> g/a instead of per repository. --offline prevents unwanted updates, >>> but it also prevents wanted updates of other, unmodified, things, and >>> new dependencies. >>> >>> >>> On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly >>> wrote: >>> On 16 March 2010 04:25, Ron Wheeler wrote: Benson Margulies wrote: > > I have this feeling that I'm missing something terribly obvious. >> >> 1: grab a tree and make some changes. >> 2: mvn. Now you've got SNAPSHOT versions in your local repository >> 3: someone else checks in a change and runs mvn deploy. Now the >> snapshot repo has jars newer than the local repo. >> > > 4: run mvn and download those over top of the local mods. > >> >> > Only if you have the update rule for your snapshot repos set to > check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed > Without patching all the version numbers, is there a best practice > or >> >> standard mechanism to stay out of this pickle? >
Re: New snapshots versus the local repo
Benson Margulies wrote: On Tue, Mar 16, 2010 at 11:18 AM, Maven User wrote: But then shouldn't you be building with what's available, not a snapshot created at some other time, At time 0, I build everything. Components a, b, c, d. At time 1, a new snapshot arrives for component a, and unless i go back and run mvn clean install on (a), it replaces my local build. But you want the new improved "a" since it should include your changes and the improvements from the other person if you are using a SCM system and communicating with the other people changing it. No tool is going to insulate you from bad human management practices. If 2 people are writing the same software module, they have to work to the same spec and coordinate themselves. Ron On Mar 16, 2010, at 10:37 AM, Benson Margulies wrote: Just for fun, I think it's worth explaining the environment. We are relatively new adopters of Maven. Up until now, we've done maven releases only for external product releases. Thus, there are snapshot dependencies amongst our internal components for months on end. To make my original scenario a trifle more concrete: I'm plugging away at a set of changes. The changes are across several aggregated components. I finish with one component, and I'm working on the next. The overall set isn't going to be done in a day, but they feel really light for a branch. Meanwhile, one of my colleagues knocks off a small fix in the component I've finished with. So, she checks in, hudson builds, and produces a snapshot. Unless I go back and rebuild my copy of that component, I get a surprise. Say that we tried to address this by making internal releases and only using snapshot dependencies 'locally,' to a build tree. Is there a plugin that will auto-edit a tree, finding all dependencies on g/a/v x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back for checkin? My fantasy continues to be that I could put a filter in my settings.xml that turned off snapshot updates on a set of g/a/v patterns. On Tue, Mar 16, 2010 at 9:00 AM, Maven User wrote: You could probably do a dependency:resolve and leverage the includes/excludes - but that starts smelling hacky. I'm in agreement with the earlier comment. If you're allowing any/all devs to deploy, it can't be a free-for-all. Why not let ci be the bottleneck (which implicitly has some degree of automated testing)? Devs have the option of deactivating tests locally On Mar 16, 2010, at 8:52 AM, Stephen Connolly wrote: I guess the issue is if you want to update some but not all of your -SNAPSHOT dependencies. Maven does not provide filtering of update checking On 16 March 2010 12:46, Maven User wrote: Google maven updatepolicy - you (as a user) can choose how often (or at all) you take versions from a repository. On Mar 16, 2010, at 8:18 AM, Benson Margulies wrote: Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: On 16 March 2010 04:25, Ron Wheeler wrote: Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If pe
Re: New snapshots versus the local repo
On Tue, Mar 16, 2010 at 11:18 AM, Maven User wrote: > But then shouldn't you be building with what's available, not a snapshot > created at some other time, At time 0, I build everything. Components a, b, c, d. At time 1, a new snapshot arrives for component a, and unless i go back and run mvn clean install on (a), it replaces my local build. > > > > On Mar 16, 2010, at 10:37 AM, Benson Margulies > wrote: > >> Just for fun, I think it's worth explaining the environment. >> >> We are relatively new adopters of Maven. Up until now, we've done >> maven releases only for external product releases. Thus, there are >> snapshot dependencies amongst our internal components for months on >> end. To make my original scenario a trifle more concrete: >> >> I'm plugging away at a set of changes. The changes are across several >> aggregated components. I finish with one component, and I'm working on >> the next. >> >> The overall set isn't going to be done in a day, but they feel really >> light for a branch. Meanwhile, one of my colleagues knocks off a small >> fix in the component I've finished with. So, she checks in, hudson >> builds, and produces a snapshot. Unless I go back and rebuild my copy >> of that component, I get a surprise. >> >> Say that we tried to address this by making internal releases and only >> using snapshot dependencies 'locally,' to a build tree. Is there a >> plugin that will auto-edit a tree, finding all dependencies on g/a/v >> x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back >> for checkin? >> >> My fantasy continues to be that I could put a filter in my >> settings.xml that turned off snapshot updates on a set of g/a/v >> patterns. >> >> >> >> >> On Tue, Mar 16, 2010 at 9:00 AM, Maven User >> wrote: >>> >>> You could probably do a dependency:resolve and leverage the >>> includes/excludes - but that starts smelling hacky. >>> >>> I'm in agreement with the earlier comment. If you're allowing any/all >>> devs >>> to deploy, it can't be a free-for-all. >>> >>> Why not let ci be the bottleneck (which implicitly has some degree of >>> automated testing)? Devs have the option of deactivating tests >>> locally >>> >>> On Mar 16, 2010, at 8:52 AM, Stephen Connolly >>> wrote: >>> I guess the issue is if you want to update some but not all of your -SNAPSHOT dependencies. Maven does not provide filtering of update checking On 16 March 2010 12:46, Maven User wrote: > Google maven updatepolicy - you (as a user) can choose how often (or at > all) you take versions from a repository. > > > On Mar 16, 2010, at 8:18 AM, Benson Margulies > wrote: > > Well, at least now we can see the disconnect. People don't want to >> >> make a branch every time they are working on something for more than a >> day. (Default snapshot update is a day.) Making a branch is fairly >> tiresome, especially given the difficulty of persuading release:branch >> to work. The 'person' who published the snapshot is hudson, just doing >> its job. >> >> If the answer is, 'always make a branch,' then that's the answer. It >> is not a popular answer with the developers I'm supporting. I wish >> there was some alternative involving controlling snapshot updates per >> g/a instead of per repository. --offline prevents unwanted updates, >> but it also prevents wanted updates of other, unmodified, things, and >> new dependencies. >> >> >> On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly >> wrote: >> >>> On 16 March 2010 04:25, Ron Wheeler >>> wrote: >>> >>> Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. > > 1: grab a tree and make some changes. > 2: mvn. Now you've got SNAPSHOT versions in your local repository > 3: someone else checks in a change and runs mvn deploy. Now the > snapshot repo has jars newer than the local repo. > 4: run mvn and download those over top of the local mods. > > Only if you have the update rule for your snapshot repos set to check >>> >>> every >>> time. >>> >>> If you are working on a branch, then run maven in offline mode to >>> prevent >>> having to worry about picking up other versions that somebody elese >>> has >>> deployed >>> >>> >>> Without patching all the version numbers, is there a best practice or > > standard mechanism to stay out of this pickle? > > > What is the pickle? You have the latest version which is what you > want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy
Re: New snapshots versus the local repo
But then shouldn't you be building with what's available, not a snapshot created at some other time, On Mar 16, 2010, at 10:37 AM, Benson Margulies wrote: Just for fun, I think it's worth explaining the environment. We are relatively new adopters of Maven. Up until now, we've done maven releases only for external product releases. Thus, there are snapshot dependencies amongst our internal components for months on end. To make my original scenario a trifle more concrete: I'm plugging away at a set of changes. The changes are across several aggregated components. I finish with one component, and I'm working on the next. The overall set isn't going to be done in a day, but they feel really light for a branch. Meanwhile, one of my colleagues knocks off a small fix in the component I've finished with. So, she checks in, hudson builds, and produces a snapshot. Unless I go back and rebuild my copy of that component, I get a surprise. Say that we tried to address this by making internal releases and only using snapshot dependencies 'locally,' to a build tree. Is there a plugin that will auto-edit a tree, finding all dependencies on g/a/v x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back for checkin? My fantasy continues to be that I could put a filter in my settings.xml that turned off snapshot updates on a set of g/a/v patterns. On Tue, Mar 16, 2010 at 9:00 AM, Maven User wrote: You could probably do a dependency:resolve and leverage the includes/excludes - but that starts smelling hacky. I'm in agreement with the earlier comment. If you're allowing any/ all devs to deploy, it can't be a free-for-all. Why not let ci be the bottleneck (which implicitly has some degree of automated testing)? Devs have the option of deactivating tests locally On Mar 16, 2010, at 8:52 AM, Stephen Connolly wrote: I guess the issue is if you want to update some but not all of your -SNAPSHOT dependencies. Maven does not provide filtering of update checking On 16 March 2010 12:46, Maven User wrote: Google maven updatepolicy - you (as a user) can choose how often (or at all) you take versions from a repository. On Mar 16, 2010, at 8:18 AM, Benson Margulies > wrote: Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: On 16 March 2010 04:25, Ron Wheeler > wrote: Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron --- --- --- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- --- --- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache
Re: Best practices
Thiessen, Todd (Todd) wrote: Interesting conversation. Let me add my two cents. We do not yet have an aggregation POM that will build everything and deploy the whole mess in a shot but that should not be difficult to construct. This statement is golden although I disagree with the "build everything" part. Each artifact, whether it be jar, war, is only built once. Any projects that need to include any of these artifacts simply reference them as a dependency. It is not built again. Our end goal is that the "mother" build simply pulls down already built artifacts and packages them up as appropriate. This mother build is thus very fast as it does little to no compiling. You are right and that is what I would like to have. It is not a big issue but is getting bigger every day as we add more WAR files to our portal. We have tended to build a lot of single purpose WARs with shared libraries rather than a small number of multi-purpose WARs. These are all versioned and deployed to a Nexus repository so I am only missing an aggregation that build me a giant tar or rar that can be shipped to the server and dropped into an unsuspecting Tomcat. There is no need for building the WAR's again. They should be ready to go. Ron It works wonderfully. There was a comment in this conversation that Maven doesn't seem to do well in this situation and that a custom lifecycle is required (I believe Phil made the comment). I don't see this myself but perhaps I didn't fully understand the comment. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Tuesday, March 16, 2010 9:04 AM To: Maven Users List Subject: Re: Best practices Phil Housley wrote: On 16 March 2010 03:08, Ron Wheeler wrote: Phil Housley wrote: On 15 March 2010 22:29, Ron Wheeler wrote: Am I missing something? There seem to be a lot of people who try to incorporate jar projects into master projects and deploy with the "Big Bang" Theory - Get everything "all right" and deploy the whole mess. They seem to generate a lot of problems for themselves. Is it not a better idea to build projects for your libraries separately, test them, deploy them on their own and then use them as dependencies in the same way that one uses dependencies from third parties? You are generally right about the best practice - modular development is almost always a good idea, but I doubt you would find a way to significantly cut down on the traffic here, as there are definitely a lot of special cases, as I know only too well. I would like to know what they are. Well, my example recently was a multi-module project where there is simply no concept of deploying a single module - the whole thing is required be pushed together, but as separate artifacts to the same place, rather than the standard method of wrapping up everything into one output artifact. Other things I have had to do in the past include horrible variant builds for different app servers. Creating self contained runnables for different systems is another fairly common but very varied issue (scripts/shaded jars/etc.) None of these are about creating generally reusable libraries, but they are all software build use cases. Also, managing lots of completely independent pieces of code is hard work. Even Maven itself is several modules combined into a project, so that a single command can build/deploy lots of pieces at once. When synchronizing releases across modules, this is really an obvious win. We have to manage about 80 3rd part libraries and we have started to accumulate our own libraries into projects that we have to manage and synchronize with deliverables. It requires a bit of brain power(self discipline) but does not require a special maven plug-in. We use proper version control with snapshots and releases. I hope that by now most heavy Maven users think like this, there is hopefully enough documentation to encourage it. However, building applications is not the same as creating libraries. We maintain a pile of libraries, and go through all the mass of branching and tagging required (with release plugin help) to look after lots of separate releases, but then there are projects which are always synchronized, so the pieces are kept together, through trunk -> branch -> tag (think like the central parts of Maven, which I notice are actually built partly with Ant.) There are some definite patterns that Maven makes work well, and maybe collecting these together would be help to people. For example, the patter
Re: searching for eclipse:m2eclipse
I removed that goal. Import your projects from M2Eclipse directly. There is no interoperability between the maven-eclipse-plugin and M2Eclipse. You have two choices: 1) Use the maven-eclipse-plugin and stock Eclipse 2) Use M2Eclipse On Mar 16, 2010, at 6:37 AM, Dominique Jean-Prost wrote: > > Hello, > > After searching everywhere, I can't find why after upgrading to > maven-eclipse-plugin 2.8, I can not use eclipse:m2eclipse anymore. > Where can I find information about this ? > regards > > > INFO] Scanning for projects... > INFO] > > ERROR] BUILD FAILURE > INFO] > > INFO] Required goal not found: eclipse:m2eclipse in > org.apache.maven.plugins:maven-eclipse-plugin:2.8 > INFO] > > INFO] For more information, run Maven with the -e switch > -- > View this message in context: > http://n2.nabble.com/searching-for-eclipse-m2eclipse-tp4743556p4743556.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 > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --
Re: New snapshots versus the local repo
Just for fun, I think it's worth explaining the environment. We are relatively new adopters of Maven. Up until now, we've done maven releases only for external product releases. Thus, there are snapshot dependencies amongst our internal components for months on end. To make my original scenario a trifle more concrete: I'm plugging away at a set of changes. The changes are across several aggregated components. I finish with one component, and I'm working on the next. The overall set isn't going to be done in a day, but they feel really light for a branch. Meanwhile, one of my colleagues knocks off a small fix in the component I've finished with. So, she checks in, hudson builds, and produces a snapshot. Unless I go back and rebuild my copy of that component, I get a surprise. Say that we tried to address this by making internal releases and only using snapshot dependencies 'locally,' to a build tree. Is there a plugin that will auto-edit a tree, finding all dependencies on g/a/v x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back for checkin? My fantasy continues to be that I could put a filter in my settings.xml that turned off snapshot updates on a set of g/a/v patterns. On Tue, Mar 16, 2010 at 9:00 AM, Maven User wrote: > You could probably do a dependency:resolve and leverage the > includes/excludes - but that starts smelling hacky. > > I'm in agreement with the earlier comment. If you're allowing any/all devs > to deploy, it can't be a free-for-all. > > Why not let ci be the bottleneck (which implicitly has some degree of > automated testing)? Devs have the option of deactivating tests locally > > On Mar 16, 2010, at 8:52 AM, Stephen Connolly > wrote: > >> I guess the issue is if you want to update some but not all of your >> -SNAPSHOT dependencies. Maven does not provide filtering of update >> checking >> >> On 16 March 2010 12:46, Maven User wrote: >> >>> Google maven updatepolicy - you (as a user) can choose how often (or at >>> all) you take versions from a repository. >>> >>> >>> On Mar 16, 2010, at 8:18 AM, Benson Margulies >>> wrote: >>> >>> Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: > On 16 March 2010 04:25, Ron Wheeler > wrote: > > Benson Margulies wrote: >> >> I have this feeling that I'm missing something terribly obvious. >>> >>> 1: grab a tree and make some changes. >>> 2: mvn. Now you've got SNAPSHOT versions in your local repository >>> 3: someone else checks in a change and runs mvn deploy. Now the >>> snapshot repo has jars newer than the local repo. >>> >> >> 4: run mvn and download those over top of the local mods. >> >>> >>> >> Only if you have the update rule for your snapshot repos set to check > > every > time. > > If you are working on a branch, then run maven in offline mode to > prevent > having to worry about picking up other versions that somebody elese has > deployed > > > >> Without patching all the version numbers, is there a best practice or >>> >>> standard mechanism to stay out of this pickle? >>> >>> >>> What is the pickle? You have the latest version which is what you >>> want >> >> if >> the person doing the deploy has done the deploy for a reason. >> If the version deployed is not better than the version that you have >> locally, you beat the crap out of the guy who deployed a version when >> they >> shouldn't have. >> >> If people deploy crap into repositories, you will have a problem >> eventually. >> If you put your version into your source management, the other person >> would >> have based his mods on yours or at least noticed the conflicts before >> he >> deployed. >> >> Collaborative software development has to be done collaboratively. >> >> Ron >> >> >> - >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>
Re: searching for eclipse:m2eclipse
Seems to be related to MECLIPSE-632 (http://www.mail-archive.com/users@maven.apache.org/msg106944.html) I was rather surprised myself that is was removed without an explicit notice. Seems like the m2eclipse guys will discontinue support for mvn eclipse:m2eclipse in m2eclipse 1.0: http://old.nabble.com/Preparing-for-M2Eclipse-1.0---no-support-for-the-maven-eclipse-plugin-td27676229.html Original-Nachricht > Datum: Tue, 16 Mar 2010 05:37:37 -0800 (PST) > Von: Dominique Jean-Prost > An: users@maven.apache.org > Betreff: searching for eclipse:m2eclipse > > Hello, > > After searching everywhere, I can't find why after upgrading to > maven-eclipse-plugin 2.8, I can not use eclipse:m2eclipse anymore. > Where can I find information about this ? > regards > > > INFO] Scanning for projects... > INFO] > > ERROR] BUILD FAILURE > INFO] > > INFO] Required goal not found: eclipse:m2eclipse in > org.apache.maven.plugins:maven-eclipse-plugin:2.8 > INFO] > > INFO] For more information, run Maven with the -e switch > -- > View this message in context: > http://n2.nabble.com/searching-for-eclipse-m2eclipse-tp4743556p4743556.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
searching for eclipse:m2eclipse
Hello, After searching everywhere, I can't find why after upgrading to maven-eclipse-plugin 2.8, I can not use eclipse:m2eclipse anymore. Where can I find information about this ? regards INFO] Scanning for projects... INFO] ERROR] BUILD FAILURE INFO] INFO] Required goal not found: eclipse:m2eclipse in org.apache.maven.plugins:maven-eclipse-plugin:2.8 INFO] INFO] For more information, run Maven with the -e switch -- View this message in context: http://n2.nabble.com/searching-for-eclipse-m2eclipse-tp4743556p4743556.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: Best practices
Interesting conversation. Let me add my two cents.
> We do not yet have an aggregation POM that will build
> everything and deploy the whole mess in a shot but that
> should not be difficult to construct.
This statement is golden although I disagree with the "build everything" part.
Each artifact, whether it be jar, war, is only built once. Any projects that
need to include any of these artifacts simply reference them as a dependency.
It is not built again. Our end goal is that the "mother" build simply pulls
down already built artifacts and packages them up as appropriate. This mother
build is thus very fast as it does little to no compiling.
It works wonderfully.
There was a comment in this conversation that Maven doesn't seem to do well in
this situation and that a custom lifecycle is required (I believe Phil made the
comment). I don't see this myself but perhaps I didn't fully understand the
comment.
> -Original Message-
> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> Sent: Tuesday, March 16, 2010 9:04 AM
> To: Maven Users List
> Subject: Re: Best practices
>
> Phil Housley wrote:
> > On 16 March 2010 03:08, Ron Wheeler
> wrote:
> >
> >> Phil Housley wrote:
> >>
> >>> On 15 March 2010 22:29, Ron Wheeler
>
> >>> wrote:
> >>>
> >>>
> Am I missing something?
>
> There seem to be a lot of people who try to incorporate jar
> projects into master projects and deploy with the "Big
> Bang" Theory
> - Get everything "all right" and deploy the whole mess.
>
> They seem to generate a lot of problems for themselves.
>
> Is it not a better idea to build projects for your libraries
> separately, test them, deploy them on their own and then
> use them
> as dependencies in the same way that one uses dependencies from
> third parties?
>
> >
> >
> >>> You are generally right about the best practice - modular
> >>> development is almost always a good idea, but I doubt you
> would find
> >>> a way to significantly cut down on the traffic here, as there are
> >>> definitely a lot of special cases, as I know only too well.
> >>>
> >> I would like to know what they are.
> >>
> >
> > Well, my example recently was a multi-module project where there is
> > simply no concept of deploying a single module - the whole thing is
> > required be pushed together, but as separate artifacts to the same
> > place, rather than the standard method of wrapping up
> everything into
> > one output artifact.
>
> > Other things I have had to do in the past include
> horrible variant
> > builds for different app servers. Creating self contained
> runnables
> > for different systems is another fairly common but very
> varied issue
> > (scripts/shaded jars/etc.) None of these are about
> creating generally
> > reusable libraries, but they are all software build use cases.
> >
> >
> >>> Also, managing lots of completely independent pieces of
> code is hard
> >>> work. Even Maven itself is several modules combined into
> a project,
> >>> so that a single command can build/deploy lots of pieces at once.
> >>> When synchronizing releases across modules, this is really an
> >>> obvious win.
> >>>
> >> We have to manage about 80 3rd part libraries and we have
> started to
> >> accumulate our own libraries into projects that we have to
> manage and
> >> synchronize with deliverables.
> >> It requires a bit of brain power(self discipline) but does not
> >> require a special maven plug-in.
> >> We use proper version control with snapshots and releases.
> >>
> >
> > I hope that by now most heavy Maven users think like this, there is
> > hopefully enough documentation to encourage it. However, building
> > applications is not the same as creating libraries. We maintain a
> > pile of libraries, and go through all the mass of branching and
> > tagging required (with release plugin help) to look after lots of
> > separate releases, but then there are projects which are always
> > synchronized, so the pieces are kept together, through
> trunk -> branch
> > -> tag (think like the central parts of Maven, which I notice are
> > actually built partly with Ant.)
> >
> >
> >>> There are some definite patterns that Maven makes work well, and
> >>> maybe collecting these together would be help to people. For
> >>> example, the pattern of project/{core,web-app,cli-app}, or
> >>> project/{ejbs,utils,web-app,ear-app}.
> >>>
> >> I was hoping to get a comprehensive list of standard
> products based
> >> on my initial list.
> >> There can not be too many things that people want to build.
> >>
> >
> > I think there are a lot more things than I would like to
> imagine, but
> > a list of common patterns, or possibly of meta-patterns,
> would be no
> > bad thing.
> >
> > I think that it would really accelerate the adooption of
> Maven by givin p
List of XML _attributes_ supported in the POM
Is there a complete list of XML _attributes_ supported in the POM? e.g. [1] [2] [1] http://www.sonatype.com/people/2007/06/how-to-merge-sub-items-from-parent-pom-to-child-pom-in-a-maven-plugin-configuration-2/ [2] http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html -- View this message in context: http://old.nabble.com/List-of-XML-_attributes_-supported-in-the-POM-tp27917908p27917908.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: Best practices
Phil Housley wrote:
On 16 March 2010 03:08, Ron Wheeler wrote:
Phil Housley wrote:
On 15 March 2010 22:29, Ron Wheeler
wrote:
Am I missing something?
There seem to be a lot of people who try to incorporate jar projects into
master projects and deploy with the "Big Bang" Theory - Get everything
"all
right" and deploy the whole mess.
They seem to generate a lot of problems for themselves.
Is it not a better idea to build projects for your libraries separately,
test them, deploy them on their own and then use them as dependencies in
the
same way that one uses dependencies from third parties?
You are generally right about the best practice - modular development
is almost always a good idea, but I doubt you would find a way to
significantly cut down on the traffic here, as there are definitely a
lot of special cases, as I know only too well.
I would like to know what they are.
Well, my example recently was a multi-module project where there is
simply no concept of deploying a single module - the whole thing is
required be pushed together, but as separate artifacts to the same
place, rather than the standard method of wrapping up everything into
one output artifact.
Other things I have had to do in the past
include horrible variant builds for different app servers. Creating
self contained runnables for different systems is another fairly
common but very varied issue (scripts/shaded jars/etc.) None of these
are about creating generally reusable libraries, but they are all
software build use cases.
Also, managing lots of completely independent pieces of code is hard
work. Even Maven itself is several modules combined into a project,
so that a single command can build/deploy lots of pieces at once.
When synchronizing releases across modules, this is really an obvious
win.
We have to manage about 80 3rd part libraries and we have started to
accumulate our own libraries into projects that we have to manage and
synchronize with deliverables.
It requires a bit of brain power(self discipline) but does not require a
special maven plug-in.
We use proper version control with snapshots and releases.
I hope that by now most heavy Maven users think like this, there is
hopefully enough documentation to encourage it. However, building
applications is not the same as creating libraries. We maintain a
pile of libraries, and go through all the mass of branching and
tagging required (with release plugin help) to look after lots of
separate releases, but then there are projects which are always
synchronized, so the pieces are kept together, through trunk -> branch
-> tag (think like the central parts of Maven, which I notice are
actually built partly with Ant.)
There are some definite patterns that Maven makes work well, and maybe
collecting these together would be help to people. For example, the
pattern of project/{core,web-app,cli-app}, or
project/{ejbs,utils,web-app,ear-app}.
I was hoping to get a comprehensive list of standard products based on my
initial list.
There can not be too many things that people want to build.
I think there are a lot more things than I would like to imagine, but
a list of common patterns, or possibly of meta-patterns, would be no
bad thing.
I think that it would really accelerate the adooption of Maven by givin people
a series of project strategies that they could use to get started.
And indeed considering these patterns can help with abstracting out
some other cases, but there will always be some things that will be
more complicated. My case involves something like one of the above
patterns, but with custom deployment requirements, and several new
packaging types, it can't be made to map neatly into a simple "build
the parts, then assemble" pattern - so I came here and asked for help.
What sort of custom deployment and package types. Can you elaborate a bit
further?
I don't want to repeat myself here, as that would drag this thread off
topic some way, but basically the situation is several modules which
are logically independent (can be built independently) but must be
deployed as a single unit, i.e. they have no general use outside the
project. The modules are built with a custom lifecycle, and
deployment is a custom process to upload to a tracker. A
multi-module build would be the logical way to proceed, so that the
entire release can be built and deployed together, but multimodule
means pom, and so no option of a custom
lifecycle, and so it would be incorrect to invoke "mvn deploy", even
though that sounds like the right command.
None of this seems that complicated, but it is an edge case that it
turns out Maven can't directly handle.
This is pretty much our state with a JSR-168 portal and its portlets
that are all separate WARs that only make sense when run as a single
deployment.
We do package up libraries that are shared (DAO, Messaging, facades,
etc) into s
Re: New snapshots versus the local repo
You could probably do a dependency:resolve and leverage the includes/ excludes - but that starts smelling hacky. I'm in agreement with the earlier comment. If you're allowing any/all devs to deploy, it can't be a free-for-all. Why not let ci be the bottleneck (which implicitly has some degree of automated testing)? Devs have the option of deactivating tests locally On Mar 16, 2010, at 8:52 AM, Stephen Connolly > wrote: I guess the issue is if you want to update some but not all of your -SNAPSHOT dependencies. Maven does not provide filtering of update checking On 16 March 2010 12:46, Maven User wrote: Google maven updatepolicy - you (as a user) can choose how often (or at all) you take versions from a repository. On Mar 16, 2010, at 8:18 AM, Benson Margulies wrote: Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: On 16 March 2010 04:25, Ron Wheeler software.com> wrote: Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New snapshots versus the local repo
On Tue, Mar 16, 2010 at 4:18 AM, Benson Margulies wrote: > If the answer is, 'always make a branch,' then that's the answer. It > is not a popular answer with the developers I'm supporting. I wish > there was some alternative involving controlling snapshot updates per > g/a instead of per repository. --offline prevents unwanted updates, > but it also prevents wanted updates of other, unmodified, things, and > new dependencies. Offline is the answer short of a branch. In any maintained and stable build, there should generally be no other snapshot dependencies than your project own ones. Using external snapshot dependencies should be an exception rather than a rule. Kalle > On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly > wrote: >> On 16 March 2010 04:25, Ron Wheeler wrote: >> >>> Benson Margulies wrote: >>> I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. >>> >>> 4: run mvn and download those over top of the local mods. >>> >> Only if you have the update rule for your snapshot repos set to check every >> time. >> >> If you are working on a branch, then run maven in offline mode to prevent >> having to worry about picking up other versions that somebody elese has >> deployed >> >> >>> Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? >>> What is the pickle? You have the latest version which is what you want if >>> the person doing the deploy has done the deploy for a reason. >>> If the version deployed is not better than the version that you have >>> locally, you beat the crap out of the guy who deployed a version when they >>> shouldn't have. >>> >>> If people deploy crap into repositories, you will have a problem >>> eventually. >>> If you put your version into your source management, the other person would >>> have based his mods on yours or at least noticed the conflicts before he >>> deployed. >>> >>> Collaborative software development has to be done collaboratively. >>> >>> Ron >>> >>> >>> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: maven-ejb-plugin & was6-maven-plugin generated jar files
For me the above fix didn't help, it deployed ok, but the classes are not
included into the final jars. I fixed the above problem as shown below. I
guess the fix is only needed for WAS60, and probably only in certain cases.
At least it works for me now.
Arthur
public void execute() throws MojoExecutionException,
MojoFailureException {
if (!getMavenProject().getPackaging().equalsIgnoreCase("ejb")) {
throw new MojoExecutionException(
"Invalid packaging type, this plugin
can only be applied to ejb
packaging type projects");
}
super.execute();
if (!getOutputJarFile().exists()) // TODO: Solve generically -
MWAS-14 -
// why doesn't failOnError fail the
// build and ws_ant return a
// returncode != 0?
{
throw new MojoExecutionException("Deployment failed -
see previous
errors");
}
File[] workingDirectorySubdirs =
getWorkingDirectory().listFiles(
(java.io.FileFilter)
DirectoryFileFilter.DIRECTORY);
if (workingDirectorySubdirs.length != 1) {
throw new MojoExecutionException("Cannot find workbench
root under "
+
getWorkingDirectory().getAbsolutePath());
}
File[] potentialRoots = workingDirectorySubdirs[0]
.listFiles((java.io.FileFilter)
DirectoryFileFilter.DIRECTORY);
if (potentialRoots.length > 2) {
throw new MojoExecutionException("Cannot find workbench
root under "
+
getWorkingDirectory().getAbsolutePath());
}
File workBenchRoot = null;
for (int i = 0; i < potentialRoots.length; i++) {
workBenchRoot = potentialRoots[i];
if (!workBenchRoot.getName().equals(".metadata")) {
break;
}
}
// copy sources
File generatedSources = new File(workBenchRoot, "ejbModule");
try {
// Create a filter for ".java" files
IOFileFilter javaSuffixFilter =
FileFilterUtils.suffixFileFilter(".java");
IOFileFilter javaFiles =
FileFilterUtils.andFileFilter(FileFileFilter.FILE, javaSuffixFilter);
FileFilter filter =
FileFilterUtils.orFileFilter(DirectoryFileFilter.DIRECTORY, javaFiles);
FileUtils.copyDirectory(generatedSources,
getGeneratedSourcesDirectory(),
filter);
FileUtils.deleteDirectory(new
File(getGeneratedSourcesDirectory(),
"META-INF"));
} catch (IOException e) {
throw new MojoExecutionException("Error copying
generated sources", e);
}
List compileSourceRoots =
getMavenProject().getCompileSourceRoots();
compileSourceRoots.add(getGeneratedSourcesDirectory().getPath());
// copy generated classes
File generatedClasses = new File(workBenchRoot, "ejbModule");
try {
// Create a filter for ".class" files
IOFileFilter classSuffixFilter =
FileFilterUtils.suffixFileFilter(".class");
IOFileFilter classFiles =
FileFilterUtils.andFileFilter(FileFileFilter.FILE, classSuffixFilter);
FileFilter filter =
FileFilterUtils.orFileFilter(DirectoryFileFilter.DIRECTORY, classFiles);
FileUtils.copyDirectory(generatedClasses,
getGeneratedClassesDirectory(),
filter);
Resource resource = new Resource();
resource.setDirectory(getGeneratedClassesDirectory().getPath());
getMavenProject().getResources().add(resource);
} catch (IOException e) {
throw new MojoExecutionException("Error copying
generated classes", e);
}
getLog().info("ejbDeploy finished");
}
--
View this message in context:
http://old.nabble.com/maven-ejb-plugin---was6-maven-plugin-generated-jar-files-tp23061582p27917297.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: New snapshots versus the local repo
I guess the issue is if you want to update some but not all of your -SNAPSHOT dependencies. Maven does not provide filtering of update checking On 16 March 2010 12:46, Maven User wrote: > Google maven updatepolicy - you (as a user) can choose how often (or at > all) you take versions from a repository. > > > On Mar 16, 2010, at 8:18 AM, Benson Margulies > wrote: > > Well, at least now we can see the disconnect. People don't want to >> make a branch every time they are working on something for more than a >> day. (Default snapshot update is a day.) Making a branch is fairly >> tiresome, especially given the difficulty of persuading release:branch >> to work. The 'person' who published the snapshot is hudson, just doing >> its job. >> >> If the answer is, 'always make a branch,' then that's the answer. It >> is not a popular answer with the developers I'm supporting. I wish >> there was some alternative involving controlling snapshot updates per >> g/a instead of per repository. --offline prevents unwanted updates, >> but it also prevents wanted updates of other, unmodified, things, and >> new dependencies. >> >> >> On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly >> wrote: >> >>> On 16 March 2010 04:25, Ron Wheeler >>> wrote: >>> >>> Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. > > 1: grab a tree and make some changes. > 2: mvn. Now you've got SNAPSHOT versions in your local repository > 3: someone else checks in a change and runs mvn deploy. Now the > snapshot repo has jars newer than the local repo. > 4: run mvn and download those over top of the local mods. > > Only if you have the update rule for your snapshot repos set to check >>> every >>> time. >>> >>> If you are working on a branch, then run maven in offline mode to prevent >>> having to worry about picking up other versions that somebody elese has >>> deployed >>> >>> >>> Without patching all the version numbers, is there a best practice or > standard mechanism to stay out of this pickle? > > > What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >>> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: New snapshots versus the local repo
Google maven updatepolicy - you (as a user) can choose how often (or at all) you take versions from a repository. On Mar 16, 2010, at 8:18 AM, Benson Margulies wrote: Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: On 16 March 2010 04:25, Ron Wheeler software.com> wrote: Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --- -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New snapshots versus the local repo
Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job. If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly wrote: > On 16 March 2010 04:25, Ron Wheeler wrote: > >> Benson Margulies wrote: >> >>> I have this feeling that I'm missing something terribly obvious. >>> >>> 1: grab a tree and make some changes. >>> 2: mvn. Now you've got SNAPSHOT versions in your local repository >>> 3: someone else checks in a change and runs mvn deploy. Now the >>> snapshot repo has jars newer than the local repo. >> >> 4: run mvn and download those over top of the local mods. >>> >> > Only if you have the update rule for your snapshot repos set to check every > time. > > If you are working on a branch, then run maven in offline mode to prevent > having to worry about picking up other versions that somebody elese has > deployed > > >> >>> Without patching all the version numbers, is there a best practice or >>> standard mechanism to stay out of this pickle? >>> >>> >> What is the pickle? You have the latest version which is what you want if >> the person doing the deploy has done the deploy for a reason. >> If the version deployed is not better than the version that you have >> locally, you beat the crap out of the guy who deployed a version when they >> shouldn't have. >> >> If people deploy crap into repositories, you will have a problem >> eventually. >> If you put your version into your source management, the other person would >> have based his mods on yours or at least noticed the conflicts before he >> deployed. >> >> Collaborative software development has to be done collaboratively. >> >> Ron >> >> >> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> >>> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANNOUNCEMENT] - Maven License Verifier Plugin 0.2-SNAPSHOT
Hello, Any progress made so far related to http://www.supose.org/issues/show/297 ? Thanks laurent 2010/3/4 Karl Heinz Marbaise : > > Hi Laurent, > > > laurent.perez wrote: >> >> I'm sorry, I don't have much time right now to look at the plugin source >> code :/ >> > You don't need to apologize, cause i say thank you for your time...I'm > working on it to see what's going wrong... > > > laurent.perez wrote: >> >> So *maybe* my licenses.xml file is wrong, I did not find a concrete >> example on the site ; you can find mine at (1). > That pushes me to enhance the documentation as well... > > Many thanks for testing and of course giving feedback to me... > > Kind regards > Karl Heinz Marbaise > -- > View this message in context: > http://old.nabble.com/-ANNOUNCEMENTMaven-License-Verifier-Plugin-0.2-SNAPSHOT-tp27658754p27778628.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 > > -- http://blog.jdeuxe.info/";>http://blog.jdeuxe.info/ - Java entreprise tips & tricks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practices
On 16 March 2010 03:08, Ron Wheeler wrote:
> Phil Housley wrote:
>>
>> On 15 March 2010 22:29, Ron Wheeler
>> wrote:
>>
>>>
>>> Am I missing something?
>>>
>>> There seem to be a lot of people who try to incorporate jar projects into
>>> master projects and deploy with the "Big Bang" Theory - Get everything
>>> "all
>>> right" and deploy the whole mess.
>>>
>>> They seem to generate a lot of problems for themselves.
>>>
>>> Is it not a better idea to build projects for your libraries separately,
>>> test them, deploy them on their own and then use them as dependencies in
>>> the
>>> same way that one uses dependencies from third parties?
>> You are generally right about the best practice - modular development
>> is almost always a good idea, but I doubt you would find a way to
>> significantly cut down on the traffic here, as there are definitely a
>> lot of special cases, as I know only too well.
>
> I would like to know what they are.
Well, my example recently was a multi-module project where there is
simply no concept of deploying a single module - the whole thing is
required be pushed together, but as separate artifacts to the same
place, rather than the standard method of wrapping up everything into
one output artifact. Other things I have had to do in the past
include horrible variant builds for different app servers. Creating
self contained runnables for different systems is another fairly
common but very varied issue (scripts/shaded jars/etc.) None of these
are about creating generally reusable libraries, but they are all
software build use cases.
>> Also, managing lots of completely independent pieces of code is hard
>> work. Even Maven itself is several modules combined into a project,
>> so that a single command can build/deploy lots of pieces at once.
>> When synchronizing releases across modules, this is really an obvious
>> win.
>
> We have to manage about 80 3rd part libraries and we have started to
> accumulate our own libraries into projects that we have to manage and
> synchronize with deliverables.
> It requires a bit of brain power(self discipline) but does not require a
> special maven plug-in.
> We use proper version control with snapshots and releases.
I hope that by now most heavy Maven users think like this, there is
hopefully enough documentation to encourage it. However, building
applications is not the same as creating libraries. We maintain a
pile of libraries, and go through all the mass of branching and
tagging required (with release plugin help) to look after lots of
separate releases, but then there are projects which are always
synchronized, so the pieces are kept together, through trunk -> branch
-> tag (think like the central parts of Maven, which I notice are
actually built partly with Ant.)
>> There are some definite patterns that Maven makes work well, and maybe
>> collecting these together would be help to people. For example, the
>> pattern of project/{core,web-app,cli-app}, or
>> project/{ejbs,utils,web-app,ear-app}.
>
> I was hoping to get a comprehensive list of standard products based on my
> initial list.
> There can not be too many things that people want to build.
I think there are a lot more things than I would like to imagine, but
a list of common patterns, or possibly of meta-patterns, would be no
bad thing.
>> And indeed considering these patterns can help with abstracting out
>> some other cases, but there will always be some things that will be
>> more complicated. My case involves something like one of the above
>> patterns, but with custom deployment requirements, and several new
>> packaging types, it can't be made to map neatly into a simple "build
>> the parts, then assemble" pattern - so I came here and asked for help.
>
> What sort of custom deployment and package types. Can you elaborate a bit
> further?
I don't want to repeat myself here, as that would drag this thread off
topic some way, but basically the situation is several modules which
are logically independent (can be built independently) but must be
deployed as a single unit, i.e. they have no general use outside the
project. The modules are built with a custom lifecycle, and
deployment is a custom process to upload to a tracker. A
multi-module build would be the logical way to proceed, so that the
entire release can be built and deployed together, but multimodule
means pom, and so no option of a custom
lifecycle, and so it would be incorrect to invoke "mvn deploy", even
though that sounds like the right command.
None of this seems that complicated, but it is an edge case that it
turns out Maven can't directly handle.
> This is a good place to ask for help since the quality and depth of
> expertise is a very good.
>
> I just have this nagging feeling that a lot of the responses are direct
> responses to the question asked rather than guidance towards "Best
> Practices" that might be much better answers in the long run.
Have to agree about the first part, and on th
Re: New snapshots versus the local repo
On 16 March 2010 04:25, Ron Wheeler wrote: > Benson Margulies wrote: > >> I have this feeling that I'm missing something terribly obvious. >> >> 1: grab a tree and make some changes. >> 2: mvn. Now you've got SNAPSHOT versions in your local repository >> 3: someone else checks in a change and runs mvn deploy. Now the >> snapshot repo has jars newer than the local repo. > > 4: run mvn and download those over top of the local mods. >> > Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed > >> Without patching all the version numbers, is there a best practice or >> standard mechanism to stay out of this pickle? >> >> > What is the pickle? You have the latest version which is what you want if > the person doing the deploy has done the deploy for a reason. > If the version deployed is not better than the version that you have > locally, you beat the crap out of the guy who deployed a version when they > shouldn't have. > > If people deploy crap into repositories, you will have a problem > eventually. > If you put your version into your source management, the other person would > have based his mods on yours or at least noticed the conflicts before he > deployed. > > Collaborative software development has to be done collaboratively. > > Ron > > > - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
RE: Maven : Problem in including/excluding some java war files in a war file.
Best practice is one output per module. Is it not possible to make multiple war outputs as different projects. Subir -Original Message- From: Sudheer Gollapudi [mailto:sudheer.gollap...@gmail.com] Sent: Tuesday, March 16, 2010 12:09 AM To: users@maven.apache.org Subject: Maven : Problem in including/excluding some java war files in a war file. Hello Iam working on a project where i have to convert the existing ANT based project to a maven project.In this process iam trying to make multiple war files out of a single source base.Iam using the maven build tag to do this and here is a sample code that iam using in my pom.xml org.apache.maven. plugins maven-war-plugin tdeinbound package war tdeinbound **/com/atx/tde/in/*.class **/com/atx/tde/in/util/*.class **/com/atx/tde/common/*.class **/com/atx/tde/common/xml/*.class **/com/atx/tde/common/xml/agreementwaiver/*.class **/com/atx/tde/common/xml/processtelematics/*.class **/com/atx/tde/common/xml/subsrenewal/*.class **/com/atx/tde/common/xml/svctermination/*.class **/com/atx/tde/common/xml/syncparty/*.class **/com/atx/tde/common/exception/*.class **/com/atx/tde/common/dataobjects/*.class **/com/atx/tde/common/constants/*.class **/com/atx/tde/out/mq/TDEMQListenerProperties.class **/com/atx/tde/out/mq/dataobjects/*.class **/com/atx/tde/out/util/*.class **/com/atx/tde/out/TDEOutboundServiceManager.class com/atx/tde/in/siebelInterface/*.class true Iam trying to include some of my source files using the include tag and iam trying to exclude some of the java files using the exclude tags.Though iam running my mvn install,the final war that is getting built is containing the entire source and its not including a sub set of classes or its not exlucding some set of classes.I have tried the following options 1.Trying with only include tag in the build sevtion. 2.Trying with only exclude tag in the build section. 3.Trying to include the include tag and the exclude tag under a " " tag but this gives a null pointer exception when running the mvn instal target. Please guide me through this Thanks for all your comments Sudheer Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven : Problem in including/excluding some java war files in a war file.
Hello Iam working on a project where i have to convert the existing ANT based project to a maven project.In this process iam trying to make multiple war files out of a single source base.Iam using the maven build tag to do this and here is a sample code that iam using in my pom.xml org.apache.maven. plugins maven-war-plugin tdeinbound package war tdeinbound **/com/atx/tde/in/*.class **/com/atx/tde/in/util/*.class **/com/atx/tde/common/*.class **/com/atx/tde/common/xml/*.class **/com/atx/tde/common/xml/agreementwaiver/*.class **/com/atx/tde/common/xml/processtelematics/*.class **/com/atx/tde/common/xml/subsrenewal/*.class **/com/atx/tde/common/xml/svctermination/*.class **/com/atx/tde/common/xml/syncparty/*.class **/com/atx/tde/common/exception/*.class **/com/atx/tde/common/dataobjects/*.class **/com/atx/tde/common/constants/*.class **/com/atx/tde/out/mq/TDEMQListenerProperties.class **/com/atx/tde/out/mq/dataobjects/*.class **/com/atx/tde/out/util/*.class **/com/atx/tde/out/TDEOutboundServiceManager.class com/atx/tde/in/siebelInterface/*.class true Iam trying to include some of my source files using the include tag and iam trying to exclude some of the java files using the exclude tags.Though iam running my mvn install,the final war that is getting built is containing the entire source and its not including a sub set of classes or its not exlucding some set of classes.I have tried the following options 1.Trying with only include tag in the build sevtion. 2.Trying with only exclude tag in the build section. 3.Trying to include the include tag and the exclude tag under a " " tag but this gives a null pointer exception when running the mvn instal target. Please guide me through this Thanks for all your comments Sudheer
