[jira] Commented: (MAVENUPLOAD-2032) Upload new version of LogFacade to m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133078#action_133078 ] Tony Dalbrekt commented on MAVENUPLOAD-2032: Sorry. Done by now. http://logfacade.googlecode.com/files/logfacade-1.1-bundle.jar > Upload new version of LogFacade to m2 repo > -- > > Key: MAVENUPLOAD-2032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2032 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Tony Dalbrekt > > New version of LogFacade released. > PLZ upload. > WHOIS to prove my domain ownership. You will see the email address here is > the same as the owner of the google code project logfacade. > http://www.whois.org/whois_new.cgi?d=jworx&tld=com -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2032) Upload new version of LogFacade to m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133079#action_133079 ] Tony Dalbrekt commented on MAVENUPLOAD-2032: Here is the link to the latest version to be uploaded. Version 1.1.1 http://logfacade.googlecode.com/files/logfacade-1.1.1-bundle.jar Skip version 1.1 > Upload new version of LogFacade to m2 repo > -- > > Key: MAVENUPLOAD-2032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2032 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Tony Dalbrekt > > New version of LogFacade released. > PLZ upload. > WHOIS to prove my domain ownership. You will see the email address here is > the same as the owner of the google code project logfacade. > http://www.whois.org/whois_new.cgi?d=jworx&tld=com -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-144) Review signature methods
[ http://jira.codehaus.org/browse/DOXIA-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-144. - Assignee: Lukas Theussl Resolution: Fixed > Review signature methods > > > Key: DOXIA-144 > URL: http://jira.codehaus.org/browse/DOXIA-144 > Project: Maven Doxia > Issue Type: Improvement > Components: Core, Modules >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Siveton >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > > Severals methods are public instead of private -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133083#action_133083
]
Lukas Theussl commented on DOXIA-236:
-
I committed some further clarifications. I was actually under the impression
that the author element had to be unique, but looking at some example code it
seems easy to generalize, so I modified the docs. Section titles may be
omitted, if they exist they must be the first child elements , and they should
(sic!) never be implicit anchors. I have reviewed the use of "should"
everywhere, please check if it is clearer.
Waiting for the next round of review... ;)
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided
DependencySet scope runtime includes jars that are scope provided - Key: MASSEMBLY-324 URL: http://jira.codehaus.org/browse/MASSEMBLY-324 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Michael Mattox I use some jars in provided scope: javax.servlet servlet-api 2.5 provided in my assembly, I specify scope as runtime: WEB-INF/lib false runtime Yet I still find the servlet-api-2.5.jar in my WAR. SInce the servlet-api is scope provided, it should be provided by the container and not included in the WAR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-35) Generate id for modules in application.xml
[
http://jira.codehaus.org/browse/MEAR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133100#action_133100
]
Julien HENRY commented on MEAR-35:
--
I'm new to EAR and WebSphere but it seems I will need an ID on the application
tag also. Here is an existing application.xml used by the old Ant build:
{code:xml}
http://java.sun.com/dtd/application_1_3.dtd";>
MyApp
app.war
/app
appuser
{code}
> Generate id for modules in application.xml
> --
>
> Key: MEAR-35
> URL: http://jira.codehaus.org/browse/MEAR-35
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Manikandan Balasubramanian
>Priority: Minor
> Fix For: 2.3.2
>
> Attachments: ear-module-id.patch, MEAR-35-maven-ear-plugin-2.patch,
> MEAR-35-maven-ear-plugin.patch
>
>
> When the ear plugin generates application.xml, it should generate an "id"
> with each module. This "id" is according to application.xml schema.
> This would help eclipse plugin to generate correct eclipse metedata.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: ActiveProjectTestJar-2.0.9.patch Here is a patch I think fixes the problem. The patch is against 2.0.9. The problem turns out to be that MavenProject.replaceWithActiveArtifact() doesn't recognize the "test-jar" dependency as a active project artifact because moduleA's packaging is "jar", not "test-jar" (obviously). What I've done is added a specific case to check if the dependency is of type test-jar and the scope of the dependency is "test". If so, the patch creates and ActiveProjectArtifact() and replaces the File inside with: new File(ref.getModelBuild().getTestOutputDirectory()) This doesn't allow production code to depend on another modules test's, but it does allow sibling tests to depend on another modules tests. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2039) rsync_ssh request for sugar.sourceforge.net
rsync_ssh request for sugar.sourceforge.net --- Key: MAVENUPLOAD-2039 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2039 Project: maven-upload-requests Issue Type: Wish Reporter: Keith Bishop "net.sf.sugar","[EMAIL PROTECTED]:/home/groups/s/su/sugar/htdocs/m2repo","rsync_ssh","Keith Bishop","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-582) Provide AspectJ 1.6 jars/poms/javadocs/sources
[ http://jira.codehaus.org/browse/MEV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen closed MEV-582. --- Fixed > Provide AspectJ 1.6 jars/poms/javadocs/sources > -- > > Key: MEV-582 > URL: http://jira.codehaus.org/browse/MEV-582 > Project: Maven Evangelism > Issue Type: Wish >Reporter: David J. M. Karlsen > Attachments: aspectjrt.tar, aspectjtools.tar, aspectjweaver.tar > > > Provide AspectJ 1.6 jars/poms/javadocs/sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MEV-582) Provide AspectJ 1.6 jars/poms/javadocs/sources
[ http://jira.codehaus.org/browse/MEV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen resolved MEV-582. - Resolution: Fixed Seems like stuff is in place now: http://repo1.maven.org/maven2/org/aspectj/aspectjweaver/1.6.0/ > Provide AspectJ 1.6 jars/poms/javadocs/sources > -- > > Key: MEV-582 > URL: http://jira.codehaus.org/browse/MEV-582 > Project: Maven Evangelism > Issue Type: Wish >Reporter: David J. M. Karlsen > Attachments: aspectjrt.tar, aspectjtools.tar, aspectjweaver.tar > > > Provide AspectJ 1.6 jars/poms/javadocs/sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MEV-582) Provide AspectJ 1.6 jars/poms/javadocs/sources
[ http://jira.codehaus.org/browse/MEV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen reopened MEV-582: - Reopening as the javadocs weren't published. > Provide AspectJ 1.6 jars/poms/javadocs/sources > -- > > Key: MEV-582 > URL: http://jira.codehaus.org/browse/MEV-582 > Project: Maven Evangelism > Issue Type: Wish >Reporter: David J. M. Karlsen > Attachments: aspectjrt.tar, aspectjtools.tar, aspectjweaver.tar > > > Provide AspectJ 1.6 jars/poms/javadocs/sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133124#action_133124
]
Benjamin Bentmann commented on DOXIA-236:
-
Fine that you pointed out the optional nulls for the sink attributes, too! Just
one concern:
bq. Section titles [...] should (sic!) never be implicit anchors.
IMHO, this should have been the opposite of the current javadocs, i.e. "must
not" add anchors on the sink side, "may" do so on the parser side.
Rationale:
I believe it's a valuable design choice if the syntax and semantics of an
output document are completely separated:
- a parser defines the semantics (text, links, formatting) by means of sink
events, i.e. it defines *what* elements constitute the document
- a sink defines the syntax for a particular output format, i.e. it defines
*how* the document will be encoded
If a parser did not emit an anchor within a section title, I don't see any
argument why a sink should be allowed to add one. This would only lead to
inconsistent behavior of the output documents: one document might have a link
and another one might have not, surprise suprise. The parser is (usually)
processing an input file from the user, so if the parser didn't get the user's
intention to output an anchor, why should the sink think differently out of a
sudden?
{noformat}
Parser: Dear sink, my master wants to output a section title.
Sink: Dear parser, I don't know your master but I know he meant to output an
anchor, too.
{noformat}
Some people would call this sink a fortune teller ;-)
Regarding the parser: If an input format defines (say as a matter of
convenience) that something like
{noformat}
* Section
{noformat}
defines an implicit anchor and is equivalent to
{noformat}
* {Section}
{noformat}
a parser simply needs to be allowed to issue both a section title and an
(implicit) anchor in case of the first input snippet. I mean, restricting the
parsers is equivalent to restricting the input formats which seems plain wrong
if Doxia wants to be open-minded.
I'm not too familar with Doxia so my understanding might be wrong. If you feel
there's more to discuss, we can simply switch over to doxia-dev where Jason and
Vincent can hopefully clarify things, too.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-165) Update velocity dependency in archetype-common pom
Update velocity dependency in archetype-common pom -- Key: ARCHETYPE-165 URL: http://jira.codehaus.org/browse/ARCHETYPE-165 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.0-alpha-3 Reporter: Anthony Whitford Please update the Maven Archetype Common dependency (http://repo1.maven.org/maven2/org/apache/maven/archetype/archetype-common/2.0-alpha-3/archetype-common-2.0-alpha-3.pom) list for Velocity. The groupId is presently "velocity", but it should be "org.apache.velocity". I am running into a pom inconsistency problem when using Artifactory. See http://www.jfrog.org/jira/browse/RTFACT-387 and http://www.nabble.com/Archetype-generate-error-to16963766.html for details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2019) Upload request for new version of jcifs: 1.2.19
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133126#action_133126 ] Carlos Sanchez commented on MAVENUPLOAD-2019: - > The jar file was uploaded to jcifs/jcifs/1.2.19, while it should have been > uploaded to org/samba/jcifs/jcifs/1.2.19. you are right, but your pom groupId is "jcifs" and should be "org.samba.jcifs" > Upload request for new version of jcifs: 1.2.19 > --- > > Key: MAVENUPLOAD-2019 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2019 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Asaf Mesika >Assignee: Carlos Sanchez > Attachments: jcifs-1.2.19-bundle.jar > > > http://jcifs.samba.org/ > JCIFS is an Open Source client library that implements the CIFS/SMB > networking protocol in 100% Java. CIFS is the standard file sharing protocol > on the Microsoft Windows platform (e.g. Map Network Drive ...). This client > is used extensively in production on large Intranets. > The bundle jar with a classes jar, sources jar and java-doc jar, is attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2032) Upload new version of LogFacade to m2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2032. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload new version of LogFacade to m2 repo > -- > > Key: MAVENUPLOAD-2032 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2032 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Tony Dalbrekt >Assignee: Carlos Sanchez > > New version of LogFacade released. > PLZ upload. > WHOIS to prove my domain ownership. You will see the email address here is > the same as the owner of the google code project logfacade. > http://www.whois.org/whois_new.cgi?d=jworx&tld=com -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2039) rsync_ssh request for sugar.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2039. --- Assignee: Carlos Sanchez Resolution: Fixed > rsync_ssh request for sugar.sourceforge.net > --- > > Key: MAVENUPLOAD-2039 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2039 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Keith Bishop >Assignee: Carlos Sanchez > > "net.sf.sugar","[EMAIL > PROTECTED]:/home/groups/s/su/sugar/htdocs/m2repo","rsync_ssh","Keith > Bishop","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3555) transitive dependency exclusion fails when classifier specified
[
http://jira.codehaus.org/browse/MNG-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trenton updated MNG-3555:
-
Attachment: pom.xml
Note the "rmi" dependency in the main dependencies section with the "provided"
scope. Also note the "client" profile.
> transitive dependency exclusion fails when classifier specified
> ---
>
> Key: MNG-3555
> URL: http://jira.codehaus.org/browse/MNG-3555
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9
> Environment: Gentoo linux
>Reporter: Trenton
>Priority: Blocker
> Attachments: pom.xml
>
>
> I have a profile like the one below. When I enable that profile, maven
> refuses to exclude the dependencies as specified, unless I remove the
> classifier. This is basically preventing us from using maven. We will have
> to stick with ant until this is resolved.
> A little bit of background. We have an rmi module and a web module. This
> profile is in the web module pom. The rmi project creates two different
> types of jars. One is the rmi server jar, the other the rmi client jar. In
> the case of the rmi server jar, all the dependencies would be required. And,
> we allow the rmi server to be run in process (under tomcat). In a case like
> that, we require all the dependencies. But, when running in standard RMI
> mode, and using the client jar, we do not need all those dependencies, nor do
> we want them to be there.
>
>
> client
>
>
>
>
> true
> ${basedir}/src/main/resources
>
> server.properties
> response_codes.properties
>
>
>
>
>
>
> ca.athabascau.banner.oros
> rmi
> 1.1.23-SNAPSHOT
> compile
> client
>
>
> ca.athabascau
> moneris-test
>
>
> com.oracle.ojdbc
> ojdbc14
>
>
> com.novell
> java-ldap
>
>
> commons-dbcp
> commons-dbcp
>
>
> commons-collections
> commons-collections
>
>
> commons-pool
> commons-pool
>
>
> cas
> casclient
>
>
> xerces
> xercesImpl
>
>
> oro
> oro
>
>
> xml-apis
> xml-apis
>
>
> javax.activation
> activation
>
>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGSITE-50) "Project information" page is lacking
"Project information" page is lacking - Key: MNGSITE-50 URL: http://jira.codehaus.org/browse/MNGSITE-50 Project: Maven 2 Project Web Site Issue Type: Wish Reporter: John Williams The "Project Information" page for Maven itself is missing most of the items that are typically present in Maven-generated project pages. Just as an example, the Surefire plugin's project information page (http://maven.apache.org/plugins/maven-surefire-plugin/project-info.html) has links for issue tracking, dependencies, and the project summary. All of these are relevant to Maven itself and most of them are present somewhere in the Maven site, but not having these links in the usual location makes them much harder to find. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNGSITE-51) quick navigation links are missing from front page
quick navigation links are missing from front page -- Key: MNGSITE-51 URL: http://jira.codehaus.org/browse/MNGSITE-51 Project: Maven 2 Project Web Site Issue Type: Improvement Reporter: John Williams All of the pages for Maven's plugins seem to have this list of links at the top of the page: "Apache | Maven 1.x | Maven 2.x | Maven 2.x Plugins | Continuum | SCM | Wagon | JXR | Doxia". All of these links are present on Maven's front page, but they are scattered about and hard to find quickly. Having these same links on all the pages related to Maven itself would be very helpful. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133147#action_133147
]
Lukas Theussl commented on DOXIA-236:
-
Thanks for the graphic illustration :)
However, I most definitely disagree with your conclusion. Curiously, I had to
defend my point several times already, so let me just direct you to some
issues: DOXIA-152, DOXIA-138 (lower part of the discussion). In short: a parser
doesn't know yet where it's output will go, some feature that might be
acceptable for one Sink may lead to errors in others. Only a Sink knows what
output is legal for its format, a Parser should therefore never insert anything
that was not explicitly there in the original input format. Otherwise you would
not be able to produce eg a pdf and a html from the same set of source
documents.
bq. restricting the parsers is equivalent to restricting the input format
I consider it a fundamental design flaw if an input format defines implicit
anchors for section titles. We have modified the original apt format (as
documentet in the doxia-apt.apt document on the doxia site) for these reasons.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2040) rsync_ssh request for domdrides.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133150#action_133150 ] James Carman commented on MAVENUPLOAD-2040: --- Proof that I own org.domdrides: http://who.godaddy.com/WhoIs.aspx?domain=domdrides.org&prog_id=godaddy > rsync_ssh request for domdrides.sourceforge.net > --- > > Key: MAVENUPLOAD-2040 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2040 > Project: maven-upload-requests > Issue Type: Wish >Reporter: James Carman > > "org.domdrides","[EMAIL > PROTECTED]:/home/groups/d/do/domdrides/htdocs/m2repo/releases","rsync_ssh","James > Carman","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2040) rsync_ssh request for domdrides.sourceforge.net
rsync_ssh request for domdrides.sourceforge.net --- Key: MAVENUPLOAD-2040 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2040 Project: maven-upload-requests Issue Type: Wish Reporter: James Carman "org.domdrides","[EMAIL PROTECTED]:/home/groups/d/do/domdrides/htdocs/m2repo/releases","rsync_ssh","James Carman","[EMAIL PROTECTED]",, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-480) Improper TestCase classes incorrectly reported as a failure of the TestSuite class
[ http://jira.codehaus.org/browse/SUREFIRE-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133151#action_133151 ] Chad La Joie commented on SUREFIRE-480: --- Yes, that error is definitely the JUnit exception that you get when you try to "run" the TestCase class. However, for me, the real issue is just the summary report produced by surefire. Instead of tracking which unit tests fail (which is know about since it's printing "<< FAILURE" on the screen it instead just reports the error with the TestCase class. If surefire could just accumulate the names of the failed test cases and use that in the summary instead of this error that would be all I needed. > Improper TestCase classes incorrectly reported as a failure of the TestSuite > class > -- > > Key: SUREFIRE-480 > URL: http://jira.codehaus.org/browse/SUREFIRE-480 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.4.2 > Environment: OS X 10.5, JDK 1.5.0_13, Maven 2.0.8 >Reporter: Chad La Joie > Fix For: Future > > > surefire creates a synthetic TestSuite from all concrete classes that match > its include configuration. If one of these classes is not a proper JUnit > TestCase (for example if it contains no test methods) surefire reports this > as a test failure on the junit.framework.TestSuite$1 class, within the > summary and surefire report, instead of an issue with the improper test > class. It does correctly flag the improper class as a failure as the plugin > reports the test results on console but if you have many tests its easy to > miss this. > It would be nice if, in the summary and the report, the improper test class > can be flagged as the failing class instead of the TestSuite class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133153#action_133153
]
Benjamin Bentmann commented on DOXIA-236:
-
bq. Thanks for the graphic illustration
Sometimes I just can't resist my brain dumps, sorry ;-)
bq. a parser doesn't know yet where it's output will go,
Yep, exactly my motivation for this issue: Since a parser can't and shouldn't
know the various sinks, he must at least know the contract of their common
interface that *every* sink obeys. If you can't setup such a common denominator
among the sinks, it's all lost with interchangable output formats.
bq. some feature that might be acceptable for one Sink may lead to errors in
others
Of course the output formats created by sinks will have different
requirements/restrictions, but every sink should
a) either fully support an event that is defined as part of the Sink API
b) or at least gracefully ignore an event it can't handle
such that users get a (best-effort) output regardless of the selected sink. It
is the responsibility of the sink implementor to shield parsers from the
details of its realized output format. IMHO, a sink should never ever fail with
an exception if the input event is valid according to the Sink API.
bq. Only a Sink knows what output is legal for its format, a Parser should
therefore never insert anything that was not explicitly there in the original
input format.
Anchor events are part of the Sink API, so a parser has to my understanding
always the right to push this event into a sink, regardless whether the event
is driven by explicit user input or by implicit convention. It is the sink's
responsibility to handle this defined event, whether it support anchors or not.
Regarding the issue of unique anchor names: This is merely another aspect that
needs to be added to the javadoc of the Sink API. If you define that anchor
names must be unique within a document then
# a conforming parser is responsible for providing this uniqueness
# a sink has all right to fail if a non-conforming parser outputs two anchor
events with the same name
bq. I consider it a fundamental design flaw if an input format defines implicit
anchors for section titles.
I am fine with your arguments against implicit anchors. However, then I still
don't understand why sinks are allowed to output implicit anchors for sections.
If we consider such anchors as problematic, nobody should be allowed to create
them. An implicit anchor is an implicit anchor, regardless whether the parser
of the sink created it, isn't it?
For example, if we consider the SiteRenderingSite to be one of those
specialized sinks that may output implicit anchors to the XHTML pages, people
could start using these auto-links to cross-reference to those sections from
external documents (of the same site). Now this a dangerous because as soon as
the users wants to output his nicely linked HTML website into a PDF book, he
will find all the auto-links not working anymore because the PdfSink doesn't
create implicit anchors like the SiteRenderingSink.
bq. We have modified the original apt format
>From SVN logs I see this was created after the last deployment of the doxia
>site (2007-11-06). If it doesn't cause any harm to the overall site, it would
>be cool to have this doc online. For example, the [APT
>Reference|http://maven.apache.org/doxia/references/apt-format.html] still
>reads "Section titles are implicitly defined anchors." which does not apply to
>the version of Doxia used by the Site Plugin, IIRC.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of event
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133159#action_133159
]
Lukas Theussl commented on DOXIA-236:
-
bq. Anchor events are part of the Sink API, so a parser has to my understanding
always the right to push this event into a sink
Not if there is no anchor in the parsed source document. Just because anchors
are valid sink events doesn't mean a parser can emit one wherever it deems
convenient.
bq. regardless whether the event is driven by explicit user input or by
implicit convention.
I disagree on the latter. A doxia parser is a translator, not an interpreter,
if you want anchors for your section titles, provide them explicitly.
bq. I still don't understand why sinks are allowed to output implicit anchors
Because there is no hard reason why they shouldn't. While there is such a
reason to forbid it for parsers (because they don't know the output format), I
don't see why it should in principle be forbidden for sinks. My personal
opinion is that implicit anchors should never be generated neither by parser
nor sink, and I think I made that clear in the javadocs, but after all,
automatically generated anchors are still a useful and widely used feature for
one single output format (html).
bq. If we consider such anchors as problematic, nobody should be allowed to
create them
The problem is not the existence of the implicit anchor, but its translation
into different output formats. If you are only interested in a html web site
for your project, I see no reason why you shouldn't be allowed to write a sink
that automatically generates those anchors for you. Of course you will be in
trouble the day you want to create a pdf from your docs. You will either have
to adjust your input documents, or use an adapted pdf sink as well. So you
could have adapted your input docs in the first place...
bq. it would be cool to have this doc online
The docs are for doxia-beta-1 which is not released yet, so we can't publish
them.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133167#action_133167
]
Benjamin Bentmann commented on DOXIA-236:
-
bq. Just because anchors are valid sink events doesn't mean a parser can emit
one wherever it deems convenient.
Yes of course, a parser should not emit events at random. What I did not
clearly express is my understanding that a parser adopts a certain input format
for usage with Doxia, just like a sink realizes some output format. Now if the
format (which is in general external and unrelated to Doxia) specifies that a
single syntactical construct like a section title is to be interpreted as a
title with an implicit anchor, a parser which wants to feed this format into
Doxia now simply can't follow the format specification because sending the
anchor event is prohibited, i.e. informataion from the input document is lost.
That's the only thing that puzzled me a little, wondering if it's really
necessary/desired. I'm fine if Doxia says "you ugly input format, don't use
implicit anchors", it's just some kind of pushing best practices, I can fairly
well understand that ;-)
bq. I don't see why it should in principle be forbidden for sinks.
Alright, as long as the implicit anchors generated by such a sink do not
interfere with the explicit anchors defined by the user (e.g. name clash).
bq. If you are only interested in a html web site for your project, I see no
reason why you shouldn't be allowed to write a sink that automatically
generates those anchors for you.
If you are only interested in -a html web site-_APT sources_ for your project,
I see no reason why you shouldn't be allowed to write a -sink-_parser_ that
automatically generates those anchors for you.
Just for the fun of the words, it wasn't meant seriously ;-)
bq. so we can't publish them.
I see, at least I know where to look for them.
To come to an end, I might not fully understand all your arguments but that's
mostly because I'm not familiar enough with Doxia's architecture. If I look
back to where this issue started, I can only repeat you did a good job and feel
this issue is ready for being closed, thanks Lukas!
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-445) myeclipse target doesn't generate spring bean files for hierarchical projects.
[ http://jira.codehaus.org/browse/MECLIPSE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Freeman updated MECLIPSE-445: - Attachment: MECLIPSE-445.zip The modified SpringBeanWriter can now find spring config files using the project root as the starting point for the search rather than the current working directory. The MyEclipse test case has been changed log each test to it's own file in the same way the rad and Eclipse tests do. There is also a test case that shows that this works. The eclipse-plugin testing framework does not recurse down to sub projects/modules when comparing results so the test results must be compared manually. > myeclipse target doesn't generate spring bean files for hierarchical projects. > -- > > Key: MECLIPSE-445 > URL: http://jira.codehaus.org/browse/MECLIPSE-445 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: MyEclipse support >Affects Versions: 2.5.1 >Reporter: Joe Freeman >Assignee: Arnaud Heritier > Fix For: 2.5.2 > > Attachments: MECLIPSE-445.zip > > > The spring bean file creation code doesn't works only when the current > working directory is the same as the project directory. This means it works > fine for single level projects. We have an n-deep hierarchy of projects > where we run the eclipse:eclipse and eclipse:myeclipse targets from the top. > In this situation, the cwd doesn't change as it traverses the hierarchy so > absolute paths must be used for navigation and then trimmed when the actual > fiile references are put in the spring beans file. I have a patch for this > but don't yet have a standalone test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: ActiveProjectTestJar-r2-2.0.9.patch The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133174#action_133174 ] jpollak edited comment on MNG-3559 at 4/30/08 7:02 PM: - The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem and replaces (obsoletes) the previous patch. was (Author: jpollak): The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: demoPom-0.0.2-src.tgz This updated demo project demonstrates the problem the -r2 patch corrects, and replaces the previously uploaded demoPom project. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests > -Dpackaging=test-jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-242) transitive dependencies do not get included
[ http://jira.codehaus.org/browse/MASSEMBLY-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133176#action_133176 ] Guillaume Egles commented on MASSEMBLY-242: --- When is this one gonna be fixed ? It really sucks that there is now way currently to include transitive dependencies. Thanks. G. > transitive dependencies do not get included > --- > > Key: MASSEMBLY-242 > URL: http://jira.codehaus.org/browse/MASSEMBLY-242 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: maven 2.0.7 >Reporter: manuel aldana >Priority: Blocker > > i am using assembly plugin with standard descriptor jar-with-dependencies. > problem is that transitive dependencies do not get included. > pom.xml from project A: > ... > a > a > 1.0 > > > tran > dep > 1.0 > > > ... > pom.xml from project B: > ... > b > b > 1.0 > > ... enabling assembly-plugin with jar-with-dependencies... > > > > a > a > 1.0 > > > ... > i am doing assembly:assembly on b:b. now tran:dep does not get included > though it is defined in a:a. that means: if i open the assembled jar-file > (from b:b) i cannot see any artifacts from tran:dep. > for earlier discussion on mailingslist see > http://www.nabble.com/assembly-plugin%3A-transitive-dependencies-do-not-get-included-tf4317601s177.html#a12308820 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
