Re: Where is the version scheme in Maven documented?
Thank you. I had come across that doc as well, but I thought it was just a proposal. Why is it not part of some user manual? Once I was told not to go by the proposals, because the actual implementation might differ. Has it been fully implemented? If yes, in which release of maven? Thanks, Sahoo Brian E. Fox wrote: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict +Resolution#DependencyMediationandConflictResolution-DependencyVersionRa nges -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sahoo Sent: Sunday, January 13, 2008 2:45 AM To: Maven Users List Subject: Where is the version scheme in Maven documented? Hi, Where is the version scheme for Maven specified? I have found some links [1,2,3] where it is briefly described, but none seems to be complete. Thanks, Sahoo [1] http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies [2] http://docs.codehaus.org/display/MAVEN/Versioning [3] http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apac he/maven/artifact/versioning/DefaultArtifactVersion.java?view=markup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie: libraries out of date in repository
On Jan 13, 2008 8:31 PM, Chris <[EMAIL PROTECTED]> wrote: > Thanks. I'm finding that quite few of the libraries I need are out of > date or incomplete (or scattered in several different places and > completely disorganized). > > How, in general, can I solve this problem without being dependent on the > dev team for each library? > > Can I create my own repository someplace on our internal network so that > all our developers at my company can point at a clean, well-organized > common repository? Or can I alter the main maven repository somehow? While it's more trouble up front, working with the project developers to get the libraries into the central repo is the best thing for the community. If the project developers aren't interested, you can submit things for upload [1]. In addition to that, it's a very good idea to establish your own internal repositories. One of the repository managers such as Archiva, Proximity or Artifactory can be very useful here, especially if you want to proxy the various remote repos you're using. [1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie: libraries out of date in repository
On 1/12/08, Chris <[EMAIL PROTECTED]> wrote: Sorry for such a noob question: How do get the most up-to-date libraries into my project? I'm using Eclipse with the m2eclipse plug-in. I enable dependency management, pick Add Dependency off the menu, and try to add the Quartz library. The Repository Search dialog offers me only Quartz 1.5.2 as the most recent version, when 1.6 is the current stable version. What are my choices for dealing with this? > As shown in the mvnrepository.com search engine: > http://www.mvnrepository.com/artifact/quartz/quartz > > Quartz 1.5.2 is the most recent release available in Maven. > > You will need to contact the Quartz dev team and ask them to please > deploy/upload a newer version into the repo. > Thanks. I'm finding that quite few of the libraries I need are out of date or incomplete (or scattered in several different places and completely disorganized). How, in general, can I solve this problem without being dependent on the dev team for each library? Can I create my own repository someplace on our internal network so that all our developers at my company can point at a clean, well-organized common repository? Or can I alter the main maven repository somehow? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices on versioning and releasing distro/installer
On Jan 9, 2008 1:47 PM, Kalle Korhonen <[EMAIL PROTECTED]> wrote: > Say, for example "application" parent, with application-distro and and > application-jar as child modules. I run the release:prepare from the parent > and I correctly get the dependencies resolved. Now the issue is that since > release:prepare only runs "test verify", building the application-distro > fails because the release-versioned application-jar isn't available yet. I > run the install of application-jar manually (note that the poms are already > modified at this point) and resume release:prepare which now succeeds. You can change the goals used during release:prepare to go all the way through the install phase. I don't really like it, but sometimes that's the only way to make things work. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where is the version scheme in Maven documented?
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict +Resolution#DependencyMediationandConflictResolution-DependencyVersionRa nges -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sahoo Sent: Sunday, January 13, 2008 2:45 AM To: Maven Users List Subject: Where is the version scheme in Maven documented? Hi, Where is the version scheme for Maven specified? I have found some links [1,2,3] where it is briefly described, but none seems to be complete. Thanks, Sahoo [1] http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies [2] http://docs.codehaus.org/display/MAVEN/Versioning [3] http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apac he/maven/artifact/versioning/DefaultArtifactVersion.java?view=markup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse has a trouble with processing .classpath file generated by maven Eclipse plug-in
Hello, Has anyone encountered this issue when using maven2 Eclipse plug-in? Basically, after I use it to generate .classpath and .project file for a project, Eclipse IDE has a trouble with processing .classpath and complains: cannot next "blah_blah_blah.../resources" inside "an_artifact_directory/src/java". To enable the nesting exlude "resources/" from "an_artifact_directory/src/java" Thanks Yan
Re: Working with Jakarta taglibs - question
So basically, the URI is chosen arbitrary, as long as it's the same value in the web.xml and in the <%@ taglib%> directive? nicolas de loof-3 wrote: > > taglibs don't require to have TLD files extracted from jars as long as you > use the taglib URI in your JSP <%@ taglib %> directives. Use maven to get > jars in your web-inf/lib and all taglibs will be detected at server > startup. > > Nico. > > > 2008/1/13, AsafM <[EMAIL PROTECTED]>: >> >> >> Hi All, >> >> I have a web application we're developing, using servlets and JSP's on >> JBoss with embedded Tomcat. >> >> We want to use Jakarta taglib, which comes as a JAR file from maven >> repository (the global one). >> >> The problem is that using it requires a manual-copy step of the .TLD >> files >> from the META-INF directory in the JAR file to our >> src/main/webapp/WEB-INF >> directory. >> >> (See instructions in http://jakarta.apache.org/taglibs/binarydist.html >> instructions for installing Jakara Taglibs ) >> >> Has anyone used Jakarta Taglibs together with maven and solved this? >> -- >> View this message in context: >> http://www.nabble.com/Working-with-Jakarta-taglibs---question-tp14787960s177p14787960.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Working-with-Jakarta-taglibs---question-tp14787960s177p14789639.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working with Jakarta taglibs - question
taglibs don't require to have TLD files extracted from jars as long as you use the taglib URI in your JSP <%@ taglib %> directives. Use maven to get jars in your web-inf/lib and all taglibs will be detected at server startup. Nico. 2008/1/13, AsafM <[EMAIL PROTECTED]>: > > > Hi All, > > I have a web application we're developing, using servlets and JSP's on > JBoss with embedded Tomcat. > > We want to use Jakarta taglib, which comes as a JAR file from maven > repository (the global one). > > The problem is that using it requires a manual-copy step of the .TLD files > from the META-INF directory in the JAR file to our src/main/webapp/WEB-INF > directory. > > (See instructions in http://jakarta.apache.org/taglibs/binarydist.html > instructions for installing Jakara Taglibs ) > > Has anyone used Jakarta Taglibs together with maven and solved this? > -- > View this message in context: > http://www.nabble.com/Working-with-Jakarta-taglibs---question-tp14787960s177p14787960.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Working with Jakarta taglibs - question
Hi All, I have a web application we're developing, using servlets and JSP's on JBoss with embedded Tomcat. We want to use Jakarta taglib, which comes as a JAR file from maven repository (the global one). The problem is that using it requires a manual-copy step of the .TLD files from the META-INF directory in the JAR file to our src/main/webapp/WEB-INF directory. (See instructions in http://jakarta.apache.org/taglibs/binarydist.html instructions for installing Jakara Taglibs ) Has anyone used Jakarta Taglibs together with maven and solved this? -- View this message in context: http://www.nabble.com/Working-with-Jakarta-taglibs---question-tp14787960s177p14787960.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merging artifacts with assembly
If the goal is to create a "new" uber jar with th correctly merged files, you should look at the maven-shade-plugin. CXF currently uses it to create a bundle jar and it does merge together various things such as the spring.handlers/schemas things. Take a look at: http://svn.apache.org/repos/asf/incubator/cxf/trunk/distribution/bundle/pom.xml Dan On Sunday 13 January 2008, Kevin Conaway wrote: > Currently, the maven assembly plugin (using the jar with dependencies > descriptor) overwrites conflicting artifacts instead of merging them. > > For example, my project depends on numerous jars from the spring > framework project. Each of these jars contains a > META-INF/spring.handlers and META-INF/spring.schemas file. > > When running the assembly, the resulting META-INF/spring.handlers and > META-INF/spring.schemas files seem to be from the jar that was last > processed. > > Is it possible to change the way the process works so that identical > filenames are merged instead of overwritten? > > Thanks, > > Kevin -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Merging artifacts with assembly
Currently, the maven assembly plugin (using the jar with dependencies descriptor) overwrites conflicting artifacts instead of merging them. For example, my project depends on numerous jars from the spring framework project. Each of these jars contains a META-INF/spring.handlers and META-INF/spring.schemas file. When running the assembly, the resulting META-INF/spring.handlers and META-INF/spring.schemas files seem to be from the jar that was last processed. Is it possible to change the way the process works so that identical filenames are merged instead of overwritten? Thanks, Kevin
Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working
Since you haven't filled a Jira issue, I did and added a packagingExcludes parameter http://jira.codehaus.org/browse/MWAR-135 Stéphane On 12/12/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: > You shouldn't use that for that. That's exactly what I meant: > warSourceExcludes is used to exclude content in the directory defined > by the warSourceDirectory. The documentation is confusing though. > > Now, I don't see any quick solution to your problem so we'll have to > investigate a bit to clarify. > > Please file a Jira issue. > > Stéphane > > On Dec 12, 2007 1:37 PM, maarten roosendaal <[EMAIL PROTECTED]> wrote: > > This is in relation to the skinny-war. I wanted to exclude all libs from > > WEB-INF\lib for all my WAR's. > > > > This also had to do with transitive dependencies in combination with > > optional = true problem. I want to include only 1 specific jar in the > > WEB-INF\lib and the rest should only be included in the manifest. I saw a > > path in JIRA but this was not working because it was missing a few classes, > > didn't look into it. > > > > Thanks, > > Maarten > > > > > > - Original Message > > From: Stephane Nicoll <[EMAIL PROTECTED]> > > To: Maven Users List > > Sent: Wednesday, December 12, 2007 12:49:21 PM > > Subject: Re: war-plugin 2.1-alpha-2-SNAPSHOT warSourceExcludes not working > > > > > > I've been changing something there indeed because it was excluding > > stuff in the resulting archive (which was not the expected behavior at > > all). I just hope I didn't break something :) > > > > Can you please elaborate because "is not working" is not especially > > helpful. > > > > this should only apply to stuff from the src/main/webapp directory. If > > you used this to filter the content of the war, it has only worked by > > side effect. > > > > Regards, > > Stéphane > > > > On Dec 12, 2007 11:19 AM, maarten roosendaal <[EMAIL PROTECTED]> > > wrote: > > > Hi, > > > > > > It seems that the option warSourceExcludes for war-plugin > > 2.1-alpha-2-SNAPSHOT is not working. I've been using alpha-1 and that was > > working > > fine. Any ideas? > > > > > > Thanks, > > > Maarten > > > > > > > > > > > > > > > > > > > > > > Looking for last minute shopping deals? > > > Find them fast with Yahoo! Search. > > http://tools.search.yahoo.com/newsearch/category.php?category=shopping > > > > > > > > -- > > Large Systems Suck: This rule is 100% transitive. If you build one, > > you suck" -- S.Yegge > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > Never miss a thing. Make Yahoo your home page. > > http://www.yahoo.com/r/hs > > > > -- > Large Systems Suck: This rule is 100% transitive. If you build one, > you suck" -- S.Yegge > -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck" -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices on versioning and releasing distro/installer
Nobody in the same boat? On 1/9/08, Kalle Korhonen <[EMAIL PROTECTED]> wrote: > > I'm facing a similar issue in a couple Maven projects where I'm creating a > a distribution package (e.g. tar.gz) or an installer (e.g rpm, Windows > installer) for a binary (jar, exe). I have a separate module for the > packager that has a dependency to the binary, and a parent pom for these. > Say, for example "application" parent, with application-distro and and > application-jar as child modules. I run the release:prepare from the parent > and I correctly get the dependencies resolved. Now the issue is that since > release:prepare only runs "test verify", building the application-distro > fails because the release-versioned application-jar isn't available yet. I > run the install of application-jar manually (note that the poms are already > modified at this point) and resume release:prepare which now succeeds. Not > too bad overall, but something I cannot imagine automating to a point of > having it in Continuum as a single-button-release. > > So I'm looking for best practices and experiences from others in similar > situations. One of the things is that I'm unsure of is if it makes any sense > to version the distro separately; in practice it should always follow the > versioning of the application itself (which I need to produce anyway; for > development and running integration tests it's unnecessary to run the > packager). I can see a few other ways to construct the build: either I can > move the distro build to the parent (but then I need to combat the problems > running assembly in a reactor build with a forked lifecycle or just run > assembly manually and forget about versioning it), or I could make the > assembly as part of the application module and simply use a different > classifier for the installer (but that doesn't sound conceptually right and > in case of Windows app/installers, both would likely produce exe types). How > are others producing distros and installers organizing their Maven projects? > > > Thanks, > Kalle >