[jira] Commented: (MEAR-17) Jar files packed in the EAR file should also be added to application.xml or manifest.mf
[ http://jira.codehaus.org/browse/MEAR-17?page=comments#action_73284 ] Stephane Nicoll commented on MEAR-17: - No, so patching the EJB modules break signatures. That's one of the reason why I don't want to do it in the EAR plugin (but you should do so in the projeet building the EJB module) Thanks for the link, it's interessting but JavaEE5 specifc for now. Regarding APP-INF/lib it's a weblogic proprietary feature, it won't work on other app server. > Jar files packed in the EAR file should also be added to application.xml or > manifest.mf > --- > > Key: MEAR-17 > URL: http://jira.codehaus.org/browse/MEAR-17 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Reporter: Kristoffer Peterhäesel > Assigned To: Stephane Nicoll > > While attempting to package an EAR for deployment on JBoss I have come across > a (for me) major issue with the way this module works. > The issue is that there are a lot dependency jars included by default. That > by itself isn't the problem. The problem is there is no way to include it in > the classpath without defining all the dependencies again in the pom.xml for > the EAR. > In an ideal world (for me) the jars would be an easy way to add the jars to > the classpath since I want to include all I need in the EAR to make it as > easy as possible to set up a depoyment environment. > There are really two options for how to do that. Either the jar files are > added to the generated Manifest.MF file or else there should be a simple > option to include all packed jar files to the application.xml. Both should > (AFAIK) work in any standard-compliant container. > The option of putting all the jar files in APP-INF/lib only works on Weblogic. -- 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-1077) Logback 0.2.5 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1077?page=comments#action_73283 ] Sebastien Pennec commented on MAVENUPLOAD-1077: --- Hello Carlos, I'll take a look at your links, thanks! Just to make things faster for this time, I've upped a jar containing the parent pom. > Logback 0.2.5 upload request > > > Key: MAVENUPLOAD-1077 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sebastien Pennec > Attachments: logback-access-0.2.5-bundle.jar, > logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar, > logback-parent-0.2.5.jar > > > The logback project recently released version 0.2.5 of all three modules. > Please kindly add the attached files to ibiblio's maven repository. -- 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: (MAVENUPLOAD-1077) Logback 0.2.5 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1077?page=all ] Sebastien Pennec updated MAVENUPLOAD-1077: -- Attachment: logback-parent-0.2.5.jar adding forgotten parent pom > Logback 0.2.5 upload request > > > Key: MAVENUPLOAD-1077 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sebastien Pennec > Attachments: logback-access-0.2.5-bundle.jar, > logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar, > logback-parent-0.2.5.jar > > > The logback project recently released version 0.2.5 of all three modules. > Please kindly add the attached files to ibiblio's maven repository. -- 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: (MRM-148) provide way of zipping the repository index for remote distribution
[ http://jira.codehaus.org/browse/MRM-148?page=comments#action_73281 ] Milos Kleint commented on MRM-148: -- as discussed on mailing list as long as the following chain works, 'm happy 1. user has a repository url in pom. 2. by contacting a predefined location in the repository, I'm able to figure out the location of the index zip 3. I download the index zpi and i'm able to map the artifacts in index to those in the repository url defined in user's pom. > provide way of zipping the repository index for remote distribution > --- > > Key: MRM-148 > URL: http://jira.codehaus.org/browse/MRM-148 > Project: Archiva > Issue Type: New Feature >Reporter: Milos Kleint > Attachments: archiver.patch > > > for use in the IDEs, it would be nice to have the index for the remote > repository readily available for download. the attached path solves that by > always creating a zip file after the index is updated and placing it into the > repository in .index folder. That way the IDE can easily check the location > only with the knowledge of the repository url. -- 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: (MRM-100) Make ProxyConfiguration into a plexus configuration object
[ http://jira.codehaus.org/browse/MRM-100?page=all ] Brett Porter closed MRM-100. Assignee: Brett Porter (was: Edwin Punzalan) Resolution: Won't Fix configuration was redone using a model > Make ProxyConfiguration into a plexus configuration object > -- > > Key: MRM-100 > URL: http://jira.codehaus.org/browse/MRM-100 > Project: Archiva > Issue Type: Improvement > Components: remote proxy >Reporter: Edwin Punzalan > Assigned To: Brett Porter > Original Estimate: 6 hours > Remaining Estimate: 6 hours > -- 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: (MRM-83) Reports should be passed a listener to be able to log their discoveries
[ http://jira.codehaus.org/browse/MRM-83?page=all ] Brett Porter updated MRM-83: Fix Version/s: 1.0-beta-1 > Reports should be passed a listener to be able to log their discoveries > --- > > Key: MRM-83 > URL: http://jira.codehaus.org/browse/MRM-83 > Project: Archiva > Issue Type: Task > Components: reporting >Affects Versions: 1.0-beta-1 >Reporter: John Tolentino > Assigned To: John Tolentino > Fix For: 1.0-beta-1 > > Original Estimate: 16 hours > Remaining Estimate: 16 hours > > - There will be different types of listeners passed in - web page, mail, etc. > - There may be more than one listener, which can be achieved through an > aggregate listener rather than crowding the interface with collections -- 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: (MRM-82) Reports should be components of their own so that new ones can be dropped in
[ http://jira.codehaus.org/browse/MRM-82?page=all ] Brett Porter updated MRM-82: Fix Version/s: 1.0-beta-1 > Reports should be components of their own so that new ones can be dropped in > > > Key: MRM-82 > URL: http://jira.codehaus.org/browse/MRM-82 > Project: Archiva > Issue Type: Task > Components: reporting >Affects Versions: 1.0-beta-1 >Reporter: John Tolentino > Fix For: 1.0-beta-1 > > Original Estimate: 16 hours > Remaining Estimate: 16 hours > -- 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: (MRM-128) better handling of jar artifacts without a pom
[ http://jira.codehaus.org/browse/MRM-128?page=all ] Brett Porter updated MRM-128: - Fix Version/s: 1.0-beta-1 > better handling of jar artifacts without a pom > -- > > Key: MRM-128 > URL: http://jira.codehaus.org/browse/MRM-128 > Project: Archiva > Issue Type: Bug > Components: indexing >Reporter: Milos Kleint > Fix For: 1.0-beta-1 > > > when indexing jar artifacts, the name and description (plus other fields) are > read from the artifact's pom file. When indexing local repository I figured > that some artifacts don't have pom files. Specifically the archetype > artifacts (see ARCHETYPE-48), there might be otehr cases. > So it would be nice to consult the pom file in the actual artifact if pom not > present. (it's stored at META-INF/maven if I recall correctly) -- 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: (MRM-60) Repository Manager should have a means to remove old snapshot builds
[ http://jira.codehaus.org/browse/MRM-60?page=all ] Brett Porter updated MRM-60: Fix Version/s: 1.0-beta-1 > Repository Manager should have a means to remove old snapshot builds > > > Key: MRM-60 > URL: http://jira.codehaus.org/browse/MRM-60 > Project: Archiva > Issue Type: New Feature >Reporter: Tim Clemons > Fix For: 1.0-beta-1 > > > A nice feature for the MRM to have would be a way to set rules on when older > SNAPSHOT builds of the form --.. should be > removed from the repository. This could either be time based (e.g. any > builds older than a month) or count based (e.g. keep only the newest 5 > builds). > In addition to the artifact itself, md5 and sha1 files should also be cleaned > out. -- 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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73279 ] Bernd commented on SUREFIRE-31: --- I could also not cleanly apply surefire-junit4.zip to the current sources. >From a quick look: current ReportEntry has no constructor of the required form. You may want to test my patches? > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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] Deleted: (MRM-71) Traverse Dependencies
[ http://jira.codehaus.org/browse/MRM-71?page=all ] Brett Porter deleted MRM-71: > Traverse Dependencies > - > > Key: MRM-71 > URL: http://jira.codehaus.org/browse/MRM-71 > Project: Archiva > Issue Type: Task >Reporter: John Tolentino > Original Estimate: 8 hours > Remaining Estimate: 8 hours > -- 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: (MRM-84) Basic statistics
[ http://jira.codehaus.org/browse/MRM-84?page=all ] Brett Porter updated MRM-84: Fix Version/s: 1.0-beta-1 > Basic statistics > > > Key: MRM-84 > URL: http://jira.codehaus.org/browse/MRM-84 > Project: Archiva > Issue Type: Task > Components: reporting >Affects Versions: 1.0-beta-1 >Reporter: John Tolentino > Fix For: 1.0-beta-1 > > Original Estimate: 16 hours > Remaining Estimate: 16 hours > -- 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: (MRM-157) add a report on artifacts that have external repositories/plugin repositories in them
add a report on artifacts that have external repositories/plugin repositories in them - Key: MRM-157 URL: http://jira.codehaus.org/browse/MRM-157 Project: Archiva Issue Type: New Feature Components: reporting Reporter: Brett Porter this may have certain constraints - eg, we report on release repo if it has any snapshot repos, etc. -- 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: (MRM-151) re-introduce index of developers and dependencies
[ http://jira.codehaus.org/browse/MRM-151?page=all ] Brett Porter updated MRM-151: - Fix Version/s: 1.0-beta-1 > re-introduce index of developers and dependencies > - > > Key: MRM-151 > URL: http://jira.codehaus.org/browse/MRM-151 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > it will be useful to identify which projects a developer are associated with, > and the dependency index will be needed to do the depended-on page on the > browse artifact page -- 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: (MRM-131) complete artifact browsing
[ http://jira.codehaus.org/browse/MRM-131?page=all ] Brett Porter updated MRM-131: - Fix Version/s: 1.0-beta-1 > complete artifact browsing > -- > > Key: MRM-131 > URL: http://jira.codehaus.org/browse/MRM-131 > Project: Archiva > Issue Type: Improvement > Components: web application >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > currently some features of the artifact display page are not implemented > (links to dependencies, displaying other information from the pom, and so on) -- 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: (MRM-156) track repositry manager base url in the metadata of a managed repository
[ http://jira.codehaus.org/browse/MRM-156?page=all ] Brett Porter updated MRM-156: - Fix Version/s: 1.0-beta-1 > track repositry manager base url in the metadata of a managed repository > > > Key: MRM-156 > URL: http://jira.codehaus.org/browse/MRM-156 > Project: Archiva > Issue Type: New Feature > Components: web application >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > repository.manager.url = http://localhost:8080/ (for requesting the index) > repository.manager.id = releases > This is needed in the metadata at the root of the repo, so that when a pom > configures a repository http://localhost:8080/releases/, the tools can > recognise where it comes from -- 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: (MRM-150) add field validations for forms
[ http://jira.codehaus.org/browse/MRM-150?page=all ] Brett Porter updated MRM-150: - Fix Version/s: 1.0-beta-1 > add field validations for forms > --- > > Key: MRM-150 > URL: http://jira.codehaus.org/browse/MRM-150 > Project: Archiva > Issue Type: Task > Components: web application >Reporter: Brett Porter > Assigned To: Maria Odea Ching > Fix For: 1.0-beta-1 > > > these are documented in the validation files by todos -- 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: (MRM-129) flush the index periodically during rebuild
[ http://jira.codehaus.org/browse/MRM-129?page=all ] Brett Porter updated MRM-129: - Fix Version/s: 1.0-beta-1 > flush the index periodically during rebuild > --- > > Key: MRM-129 > URL: http://jira.codehaus.org/browse/MRM-129 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > currently, the indexing can take some time when it is done from scratch on a > large repository, and requires a large amount of memory. It would be good to > periodically checkpoint the index with a set of artifacts already completed. > How this affects the timestamp used needs to be interpreted, as if the > indexing is stopped it may want to avoid reindexing those already done. > Perhaps an alternative is to sort the discovered artifacts by timestamp, and > setting it to the most recent one done - this can be considered in > conjunction with the current issue that synced artifacts sometimes are new > but have a timestamp older than the last indexing time and so are not indexed. -- 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: (MRM-145) identify skins and adjust type in index accordingly
[ http://jira.codehaus.org/browse/MRM-145?page=all ] Brett Porter updated MRM-145: - Fix Version/s: 1.0-beta-1 > identify skins and adjust type in index accordingly > --- > > Key: MRM-145 > URL: http://jira.codehaus.org/browse/MRM-145 > Project: Archiva > Issue Type: Improvement > Components: indexing >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > like we identify archetypes, attempt to identify skins and index them > accordingly. > It may be beneficial to introduce a proper packaging type for this in Maven > itself. > While it is not entirely deterministic (as a skin is simply a set of files > laid onto the site), the existence of one of css/maven-base.css and site.vm > would be a reliable predictor. -- 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: (MRM-76) Front End web user interface for configuring multiple repository proxy
[ http://jira.codehaus.org/browse/MRM-76?page=all ] Brett Porter closed MRM-76. --- Assignee: Brett Porter Resolution: Fixed I've done this > Front End web user interface for configuring multiple repository proxy > -- > > Key: MRM-76 > URL: http://jira.codehaus.org/browse/MRM-76 > Project: Archiva > Issue Type: Task >Reporter: John Tolentino > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > > For configuring multiple repository proxy. -- 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: (MRM-135) integrate repository sync and conversion in the main application
[ http://jira.codehaus.org/browse/MRM-135?page=all ] Brett Porter updated MRM-135: - Fix Version/s: (was: 1.0-beta-1) > integrate repository sync and conversion in the main application > > > Key: MRM-135 > URL: http://jira.codehaus.org/browse/MRM-135 > Project: Archiva > Issue Type: New Feature > Components: repository-converter, partner sync, scheduling >Reporter: Brett Porter > -- 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: (WAGONHTTP-5) The getIfNewer method fails to work if file doesn't exist locally and the Last-Modified header isn't sent by the server
[ http://jira.codehaus.org/browse/WAGONHTTP-5?page=all ]
Brett Porter closed WAGONHTTP-5.
Resolution: Fixed
Fix Version/s: 1.0-beta-2
good point. fixed by adding an || timestamp == 0 on the check so that will
force a download.
> The getIfNewer method fails to work if file doesn't exist locally and the
> Last-Modified header isn't sent by the server
> ---
>
> Key: WAGONHTTP-5
> URL: http://jira.codehaus.org/browse/WAGONHTTP-5
> Project: wagon-http
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Kohsuke Kawaguchi
> Assigned To: Brett Porter
> Fix For: 1.0-beta-2
>
>
> The code doesn't work correctly if the following two conditions are met
> simultaneously:
> (i) the local file doesn't exist --- hence the timestamp parameter is 0
> (ii) the remote server doesn't send the "Last-Modified" header.
> Since the lastModified variable is initialized to 0 in line 355, if the above
> two conditions are met,
> the following if statement at line 371 evaluates to false:
> *if ( timestamp < lastModified )
> {
> retValue = true;
> and therefore the file won't be downloaded, causing the dependency to fail.
> This used to work with Maven 1.0.2.
> To fix this problem, initialize the lastModified variable to 1.
--
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: (WAGONHTTP-5) The getIfNewer method fails to work if file doesn't exist locally and the Last-Modified header isn't sent by the server
[ http://jira.codehaus.org/browse/WAGONHTTP-5?page=all ]
Lukas Theussl reopened WAGONHTTP-5:
---
Please reconsider this. Calling get(String, File) does not solve the issue,
actually it will have exactly the same effect, as it only calls get( String,
File, long ) with zero timestamp. To really work around the problem one would
have to call get( String, File, long ) with a negative timestamp, which is not
logical. The timestamp parameter is usually determined by File.lastModified(),
which returns zero for files that do not exist, I think wagon should handle
this case accordingly.
> The getIfNewer method fails to work if file doesn't exist locally and the
> Last-Modified header isn't sent by the server
> ---
>
> Key: WAGONHTTP-5
> URL: http://jira.codehaus.org/browse/WAGONHTTP-5
> Project: wagon-http
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Kohsuke Kawaguchi
> Assigned To: Brett Porter
>
> The code doesn't work correctly if the following two conditions are met
> simultaneously:
> (i) the local file doesn't exist --- hence the timestamp parameter is 0
> (ii) the remote server doesn't send the "Last-Modified" header.
> Since the lastModified variable is initialized to 0 in line 355, if the above
> two conditions are met,
> the following if statement at line 371 evaluates to false:
> *if ( timestamp < lastModified )
> {
> retValue = true;
> and therefore the file won't be downloaded, causing the dependency to fail.
> This used to work with Maven 1.0.2.
> To fix this problem, initialize the lastModified variable to 1.
--
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: (MRM-140) logging misconfiguration
[ http://jira.codehaus.org/browse/MRM-140?page=all ] Brett Porter closed MRM-140. Assignee: Brett Porter Resolution: Fixed fixed by ensuring container is initialised only once. The logger manager was not being loaded from application.xml because it was already initialised with defaults. > logging misconfiguration > > > Key: MRM-140 > URL: http://jira.codehaus.org/browse/MRM-140 > Project: Archiva > Issue Type: Bug > Components: web application >Reporter: Brett Porter > Assigned To: Brett Porter > Fix For: 1.0-beta-1 > > > it seems since switching to the new plexus-xwork integration that the logging > is not correct or complete (perhaps just that it is initialised later than > some things need to log), going by the warning that appears on startup. -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73274 ] Brett Porter commented on MRM-155: -- could you include tests that produce the problem that this fixes too, please? Also, I'd prefer one diff using svn diff that marks out each file that gets patched. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > LegacyArtifactDiscoverer.java.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.jar -- 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: (MRM-154) DigestUtils fails to verify checksum from ibiblio
[ http://jira.codehaus.org/browse/MRM-154?page=comments#action_73273 ]
Brett Porter commented on MRM-154:
--
thanks, would you mind including a test case?
also, it's important that the diff be taken from the level of pom.xml to make
it easier to apply. I'm not sure how you are generating these but they don't
even contain the filename.
> DigestUtils fails to verify checksum from ibiblio
> -
>
> Key: MRM-154
> URL: http://jira.codehaus.org/browse/MRM-154
> Project: Archiva
> Issue Type: Bug
>Reporter: nicolas de loof
> Attachments: DigestUtils.java.patch
>
>
> Downloading servletapi-24.pom fails.
> DigestUtils.cleanChecksum check for filename in remote checksum file to be
> same as local, but tets is inverted :
> String filename = m.group( 2 );
> if ( !path.endsWith( filename ) )
> {
> throw new DigesterException( "Supplied checksum does not
> match checksum pattern" );
> }
> filename =
> "/home/projects/maven/repository-staging/to-ibiblio/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom"
> path = "servletapi-2.4.pom".
> Patch provided to test if ( !path.endsWith( filename ) )
--
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: (MRM-152) LegacyArtifactDiscoverer doesn"t handle "javadoc.jars" type
[ http://jira.codehaus.org/browse/MRM-152?page=comments#action_73272 ] Brett Porter commented on MRM-152: -- test case? > LegacyArtifactDiscoverer doesn"t handle "javadoc.jars" type > --- > > Key: MRM-152 > URL: http://jira.codehaus.org/browse/MRM-152 > Project: Archiva > Issue Type: Improvement > Components: discovery >Reporter: nicolas de loof > Attachments: LegacyArtifactDiscoverer.java.patch > > > "javadoc.jars" type is used in maven1 repo for javadoc bundles. It is not > commonly used, but support for it has recently be added to eclipse plugin, > and it can be usefull for non-redistribuable artifacts that have private > 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] Created: (MRM-156) track repositry manager base url in the metadata of a managed repository
track repositry manager base url in the metadata of a managed repository Key: MRM-156 URL: http://jira.codehaus.org/browse/MRM-156 Project: Maven Repository Manager Issue Type: New Feature Components: web application Reporter: Brett Porter repository.manager.url = http://localhost:8080/ (for requesting the index) repository.manager.id = releases This is needed in the metadata at the root of the repo, so that when a pom configures a repository http://localhost:8080/releases/, the tools can recognise where it comes from -- 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: (MRM-148) provide way of zipping the repository index for remote distribution
[ http://jira.codehaus.org/browse/MRM-148?page=comments#action_73270 ] Brett Porter commented on MRM-148: -- how do you think we can resolve this issue? I'd suggest: - adding a configuration option for where to store the index file. In the local repository actually sounds fine as a default - offer it for download from an action URL instead of relying on it being in the filesystem somewhere. wdyt? > provide way of zipping the repository index for remote distribution > --- > > Key: MRM-148 > URL: http://jira.codehaus.org/browse/MRM-148 > Project: Maven Repository Manager > Issue Type: New Feature >Reporter: Milos Kleint > Attachments: archiver.patch > > > for use in the IDEs, it would be nice to have the index for the remote > repository readily available for download. the attached path solves that by > always creating a zip file after the index is updated and placing it into the > repository in .index folder. That way the IDE can easily check the location > only with the knowledge of the repository url. -- 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: (WAGONHTTP-5) The getIfNewer method fails to work if file doesn't exist locally and the Last-Modified header isn't sent by the server
[ http://jira.codehaus.org/browse/WAGONHTTP-5?page=all ]
Brett Porter closed WAGONHTTP-5.
Assignee: Brett Porter
Resolution: Won't Fix
Fix Version/s: (was: 1.0-alpha-7)
I disagree with this fix.
Instead of passing in '0', I think the caller should use get() if the file
doesn't exist and getIfNewer() otherwise.
> The getIfNewer method fails to work if file doesn't exist locally and the
> Last-Modified header isn't sent by the server
> ---
>
> Key: WAGONHTTP-5
> URL: http://jira.codehaus.org/browse/WAGONHTTP-5
> Project: wagon-http
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Kohsuke Kawaguchi
> Assigned To: Brett Porter
>
> The code doesn't work correctly if the following two conditions are met
> simultaneously:
> (i) the local file doesn't exist --- hence the timestamp parameter is 0
> (ii) the remote server doesn't send the "Last-Modified" header.
> Since the lastModified variable is initialized to 0 in line 355, if the above
> two conditions are met,
> the following if statement at line 371 evaluates to false:
> *if ( timestamp < lastModified )
> {
> retValue = true;
> and therefore the file won't be downloaded, causing the dependency to fail.
> This used to work with Maven 1.0.2.
> To fix this problem, initialize the lastModified variable to 1.
--
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-1091) Upload ognl:ognl:2.6.9 to ibiblio
Upload ognl:ognl:2.6.9 to ibiblio - Key: MAVENUPLOAD-1091 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1091 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/ognl-2.6.9-bundle.jar http://www.ognl.org/ OGNL stands for Object-Graph Navigation Language; it is an expression language for getting and setting properties of Java objects. This bundle also contains javadoc and sources jars. -- 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: (MNG-2529) it0063... FAILED
[ http://jira.codehaus.org/browse/MNG-2529?page=comments#action_73268 ] Brett Porter commented on MNG-2529: --- this is because the profile only adds tools.jar on a sun distribution. This is correct for sun distributions and for apple distributions (where the tools are always in the classpath). We need to cover blackdown and maybe others too. While it should be easy to fix this test, we should consider the impact this has on other parts of the system that use tools.jar > it0063... FAILED > > > Key: MNG-2529 > URL: http://jira.codehaus.org/browse/MNG-2529 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.1 > Environment: blackdown-jdk-1.4.2.03 / GNU/LInux >Reporter: Hilco Wijbenga > > 1 of the 101 integration tests fails. > it0063... FAILED > - Standard Out - > Command: /home/maven/bin/maven/current/bin/mvn -e --no-plugin-registry > --batch-mode -Dmaven.repo.local=/home/maven/.m2/repository clean:clean package > - Standard Error - > Exit code: 1 > >> Error Stacktrace: > org.apache.maven.it.VerificationException > at org.apache.maven.it.Verifier.executeGoals(Verifier.java:732) > at org.apache.maven.it.Verifier.main(Verifier.java:964) > << Error Stacktrace > Log file contents: > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'clean'. > [INFO] > > [INFO] Building Unnamed - org.apache.maven.it:maven-core-it0063:jar:1.0 > [INFO]task-segment: [clean:clean, package] > [INFO] > > [INFO] [clean:clean] > [INFO] Deleting directory > /home/maven/maven/components/maven-core-it/it0063/target > [INFO] Deleting directory > /home/maven/maven/components/maven-core-it/it0063/target/classes > [INFO] Deleting directory > /home/maven/maven/components/maven-core-it/it0063/target/test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 1 source file to > /home/maven/maven/components/maven-core-it/it0063/target/classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > /home/maven/maven/components/maven-core-it/it0063/src/main/java/org/apache/maven/it0001/Person.java:[3,27] > package com.sun.tools.javac does not exist > [INFO] > > [INFO] Trace > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) > 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:324) > 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.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417) > at > org.a
[jira] Created: (MNG-2529) it0063... FAILED
it0063... FAILED Key: MNG-2529 URL: http://jira.codehaus.org/browse/MNG-2529 Project: Maven 2 Issue Type: Bug Components: Bootstrap & Build Affects Versions: 2.1 Environment: blackdown-jdk-1.4.2.03 / GNU/LInux Reporter: Hilco Wijbenga 1 of the 101 integration tests fails. it0063... FAILED - Standard Out - Command: /home/maven/bin/maven/current/bin/mvn -e --no-plugin-registry --batch-mode -Dmaven.repo.local=/home/maven/.m2/repository clean:clean package - Standard Error - Exit code: 1 >> Error Stacktrace: org.apache.maven.it.VerificationException at org.apache.maven.it.Verifier.executeGoals(Verifier.java:732) at org.apache.maven.it.Verifier.main(Verifier.java:964) << Error Stacktrace Log file contents: + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'clean'. [INFO] [INFO] Building Unnamed - org.apache.maven.it:maven-core-it0063:jar:1.0 [INFO]task-segment: [clean:clean, package] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /home/maven/maven/components/maven-core-it/it0063/target [INFO] Deleting directory /home/maven/maven/components/maven-core-it/it0063/target/classes [INFO] Deleting directory /home/maven/maven/components/maven-core-it/it0063/target/test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 1 source file to /home/maven/maven/components/maven-core-it/it0063/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/maven/maven/components/maven-core-it/it0063/src/main/java/org/apache/maven/it0001/Person.java:[3,27] package com.sun.tools.javac does not exist [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Compilation failure at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747) at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) 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:324) 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.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 17 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Fri Aug 25 02:00:21 GMT 2006 FATAL ERROR: Unable to configure the Maven application Error stacktrace: org.apache.maven.reactor.MavenExecutionException: Compilation failure at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:206) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747) at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[jira] Updated: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: CONTINUUM-755-continuum-webapp.patch Attached patch for validating Project form and Schedule form. > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Attachments: CONTINUUM-755-continuum-webapp.patch > > Original Estimate: 1 day, 6 hours > Time Spent: 1 day, 8 hours > Remaining Estimate: 0 minutes > -- 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: (MJAVADOC-72) Aggregating javadocs doesn't work
[ http://jira.codehaus.org/browse/MJAVADOC-72?page=all ] Vincent Siveton closed MJAVADOC-72. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Applied with small changes (codestyle) Bump to 1.0-beta-2-SNAPSHOT for maven-plugin-testing-harness to prevent test failures. Thanks Mathias! > Aggregating javadocs doesn't work > - > > Key: MJAVADOC-72 > URL: http://jira.codehaus.org/browse/MJAVADOC-72 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: WinXP SP2 > cygwin 1.5.19 > maven 2.0.4 > jdk 1.5.0_06 > javadoc-plugin 2.0 final > latest released plugins >Reporter: Bugittaa Pahasti > Assigned To: Vincent Siveton > Fix For: 2.1 > > Attachments: MJAVADOC-72.patch > > > When I define true to javadoc plugin configuration in > parent pom, javadoc generation doesn't work from the parent (all other > configuration options are default). If run under individual components, > javadoc is generated without problems. It seems that the child dependencies > aren't resolved: > Embedded error: Exit code: 1 - > c:/code/apps/project/common/src/main/java/com/company/AbstractLogEnabled.java:3: > package org.apache.log4j does not exist > import org.apache.log4j.Logger; > c:/code/apps/component/common-test/src/main/java/com/company/unittest/AbstractDatasourceEnabledTestCase.java:11: > package org.apache.commons.dbcp does not exist > import org.apache.commons.dbcp.BasicDataSource; > And lot more similar errors. > Additionally, there are a huge number of ClassCastExceptions from javadoc. > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > at > com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804) > at > com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85) > at > com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40) > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155) > at > com.sun.tools.doclets
[jira] Commented: (MSITE-151) Ability to change the site directory in the plugin configuration in the pom.xml file.
[ http://jira.codehaus.org/browse/MSITE-151?page=comments#action_73264 ] Chris Hilton commented on MSITE-151: I believe this is a duplicate of MSITE-91, but I would really like to see it fixed. > Ability to change the site directory in the plugin configuration in the > pom.xml file. > - > > Key: MSITE-151 > URL: http://jira.codehaus.org/browse/MSITE-151 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-5 > Environment: All >Reporter: Mark Soderquist > Fix For: 2.0 > > Attachments: AbstractSiteMojo.diff > > > Added the ability to change the site directory via the plugin configuration > in the pom.xml file. This completes an existing TODO in the code. Attached is > the SVN diff file for the patch. -- 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-17) Jar files packed in the EAR file should also be added to application.xml or manifest.mf
[ http://jira.codehaus.org/browse/MEAR-17?page=comments#action_73263 ] Steve Loughran commented on MEAR-17: Sun's belief that you should patch the EJB modules is bollocks, because it doesnt take in to account signed JAR files, does it? On a brighter note while j2ee 1.5 spec doesnt come out and document it anywhere, there may a element in the ear http://docs.sun.com/app/docs/doc/819-3659/6n5s6m57h?a=view This will point to the location of the library dir, and it appears to default to /lib if not set. Now, if EAR files point it at APP-INF/lib you get the same settings for weblogic as for java5.. Of course, jboss4.x doesnt handle the 1.5 descriptor. There are some hints in its docs that it takes the APP-INF/lib dir, but I dont see it working for me. > Jar files packed in the EAR file should also be added to application.xml or > manifest.mf > --- > > Key: MEAR-17 > URL: http://jira.codehaus.org/browse/MEAR-17 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Reporter: Kristoffer Peterhäesel > Assigned To: Stephane Nicoll > > While attempting to package an EAR for deployment on JBoss I have come across > a (for me) major issue with the way this module works. > The issue is that there are a lot dependency jars included by default. That > by itself isn't the problem. The problem is there is no way to include it in > the classpath without defining all the dependencies again in the pom.xml for > the EAR. > In an ideal world (for me) the jars would be an easy way to add the jars to > the classpath since I want to include all I need in the EAR to make it as > easy as possible to set up a depoyment environment. > There are really two options for how to do that. Either the jar files are > added to the generated Manifest.MF file or else there should be a simple > option to include all packed jar files to the application.xml. Both should > (AFAIK) work in any standard-compliant container. > The option of putting all the jar files in APP-INF/lib only works on Weblogic. -- 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: (MPCHANGES-32) The encoding of the changes.xml file is not preserved after doing release-version
[ http://jira.codehaus.org/browse/MPCHANGES-32?page=all ] Lukas Theussl closed MPCHANGES-32. -- Resolution: Fixed > The encoding of the changes.xml file is not preserved after doing > release-version > - > > Key: MPCHANGES-32 > URL: http://jira.codehaus.org/browse/MPCHANGES-32 > Project: maven-changes-plugin > Issue Type: Bug >Reporter: Lukas Theussl > Assigned To: Lukas Theussl > Fix For: 1.6.1 > > > This is a follow-up of MPCHANGES-24: if we upgrade dom4j, we will be able to > fix this in a more satisfactory way. -- 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: (CONTINUUM-802) Use fine grained permissions per project group
[ http://jira.codehaus.org/browse/CONTINUUM-802?page=all ] Carlos Sanchez closed CONTINUUM-802. Resolution: Fixed Fix Version/s: 1.1 > Use fine grained permissions per project group > -- > > Key: CONTINUUM-802 > URL: http://jira.codehaus.org/browse/CONTINUUM-802 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > -- 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-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73261 ] Jian Wu commented on SUREFIRE-31: - Hi, I found that I can use the apache.snapshots repository at: apache.snapshots http://people.apache.org/repo/m2-snapshot-repository But, I encountered the following up problem: [INFO] Scanning for projects... [INFO] - --- [INFO] Building SureFire JUnit 4.0 Runner [INFO]task-segment: [compile] [INFO] - --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 3 source files to C:\TrinityPrj\maven2\surefire-junit4\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\TrinityPrj\maven2\surefire-junit4\src\main\java\org\apache\maven\surefire\jun it\RunListenerInvocationHandler.java:[153,29] cannot find symbol symbol : constructor ReportEntry(java.lang.Object,java.lang.String,java.lang.St ring,java.lang.Throwable) location: class org.apache.maven.surefire.report.ReportEntry C:\TrinityPrj\maven2\surefire-junit4\src\main\java\org\apache\maven\surefire\jun it\JUnit4TestSet.java:[109,53] invoke(java.lang.Object,java.lang.Object...) in j ava.lang.reflect.Method cannot be applied to (java.lang.Object) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Aug 24 14:56:48 PDT 2006 [INFO] Final Memory: 2M/11M [INFO] Any suggestion to work-around it would be really appreciated! Thanks, Jian > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement >Reporter: John Didion > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-1080) Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1080?page=comments#action_73257 ] Matt Whitlock commented on MAVENUPLOAD-1080: Was just going on http://www.ibiblio.org/maven2/org/eclipse/jdt/core/3.2.0.658/core-3.2.0.658.pom as a basis for 3.2.0.666. That POM has even less information than the one I submitted. > Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio > > > Key: MAVENUPLOAD-1080 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1080 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/core-3.2.0.666-bundle.jar > http://www.eclipse.org/jdt/ -- 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: (MEV-435) Incorrect POM for xdoclet-bea-module.
[ http://jira.codehaus.org/browse/MEV-435?page=comments#action_73251 ] Carlos Sanchez commented on MEV-435: poms can't be changed, contact them to fix next releases > Incorrect POM for xdoclet-bea-module. > - > > Key: MEV-435 > URL: http://jira.codehaus.org/browse/MEV-435 > Project: Maven Evangelism > Issue Type: Improvement >Reporter: Davy Toch > > The POM should also include a dependency to xdoclet-web-module. -- 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: (MEV-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_73256 ] Jimisola Laursen commented on MEV-413: -- Missed your first comment on this issue. Here is the same explaination that I had in the initial description: "a stripped down of Xerces is included with the 1.5 JRE and having addition Xerces libraries in the classpath causes major problems unless placed under lib/endorsed (at least to my knowledge)" Hence, it doesn't run satisfyingly out-of-the-box. Also, are really all these libraries a must (minimum requirement) for Jaxen to run? Whenever I use Jaxen in a Maven Project I have to start with the above exclude. If I am missing out on something I gladly hear some advice on this matter. What did you mean by "maybe you need to fork your tests or do some other configuration to avoid the problems. "? I haven't said anything about tests. Adding them to dependencies clearly seems to be my problem. > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=all ] Jimisola Laursen reopened MEV-413: -- > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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: (MSITE-138) site:stage does not create xref
[ http://jira.codehaus.org/browse/MSITE-138?page=comments#action_73254 ] Vincent Siveton commented on MSITE-138: --- Hi jorg, (For the next time, please use dev@maven.apache.org instead of jira for these sorts of question) To build the plugins project [1], you need Maven 2.0.5 or more. You could build Maven from sources [2] or download a CI distribution [3] with 2.1-SNAPSHOT. Due to some cyclic references in the plugins dependencies, the actual plugins pom [4] will fail. You could comment out some modules or build individually each plugin wanted. FYI MNG-2410 will block a release of site plugin until Maven 2.1 (see svn r430446). For your last question, the bug was for external reports (like jxr, javadoc) in the stage goal. HTH. Vincent [1] http://svn.apache.org/repos/asf/maven/plugins/trunk [2] http://maven.apache.org/guides/development/guide-building-m2.html [3] http://maven.zones.apache.org/~maven/builds/trunk/ [4] http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml > site:stage does not create xref > --- > > Key: MSITE-138 > URL: http://jira.codehaus.org/browse/MSITE-138 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jorg Heymans > Assigned To: Vincent Siveton > Fix For: 2.0 > > > as reported here : > http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/40178 > the xref and test-xref dirs both have an empty index.html after the site is > staged. -- 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-1090) Upload of Maven Docbkx Plugin
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1090?page=comments#action_73240 ] Carlos Sanchez commented on MAVENUPLOAD-1090: - plugin uploads won't work, you need to setup your own repo and follow instructions to get it synced at the end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html and http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/bin/m2-sync/conf/ > Upload of Maven Docbkx Plugin > - > > Key: MAVENUPLOAD-1090 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1090 > Project: maven-upload-requests > Issue Type: Task >Reporter: Wilfred Springer > > http://www.agilejava.com/downloads/docbkx-builder-maven-plugin-0.8-bundle.jar > http://www.agilejava.com/downloads/docbkx-maven-base-0.8-bundle.jar > http://www.agilejava.com/downloads/docbkx-maven-plugin-1.69.1.7-bundle.jar > An alternative for the Maven DocBook plugin found at mojo.codehaus.org. -- 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-1088) Upload drools:drools-decisiontables:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1088?page=all ] Carlos Sanchez closed MAVENUPLOAD-1088. --- Assignee: Carlos Sanchez Resolution: Fixed next time please put all bundle urls in only one issue > Upload drools:drools-decisiontables:3.0.4 to ibiblio > > > Key: MAVENUPLOAD-1088 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1088 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/drools-decisiontables-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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-1081) Upload org.apache.jakarta.commons:commons-jci-eclipse:3.2.0.666 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1081?page=all ] Carlos Sanchez closed MAVENUPLOAD-1081. --- Assignee: Carlos Sanchez Resolution: Won't Fix apache artifacts must be upload by each apache project, anyway this doesn't look like an apache artifact and more like an eclipse one > Upload org.apache.jakarta.commons:commons-jci-eclipse:3.2.0.666 to ibiblio > -- > > Key: MAVENUPLOAD-1081 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1081 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/commons-jci-eclipse-3.2.0.666-bundle.jar > http://jakarta.apache.org/commons/sandbox/jci/ -- 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-1083) Upload org.apache.jakarta.commons:commons-jci-core:1.0-406301 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1083?page=all ] Carlos Sanchez closed MAVENUPLOAD-1083. --- Assignee: Carlos Sanchez Resolution: Won't Fix apache artifacts must be upload by each apache project, anyway this doesn't look like an apache artifact and more like an eclipse one > Upload org.apache.jakarta.commons:commons-jci-core:1.0-406301 to ibiblio > > > Key: MAVENUPLOAD-1083 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1083 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/commons-jci-core-1.0-406301-bundle.jar > http://jakarta.apache.org/commons/sandbox/jci/ -- 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: (MEV-436) JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it needs connector-1.5.
[ http://jira.codehaus.org/browse/MEV-436?page=comments#action_73250 ] Carlos Sanchez commented on MEV-436: poms can't be changed, we'll keep this open for future releases > JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it needs > connector-1.5. > -- > > Key: MEV-436 > URL: http://jira.codehaus.org/browse/MEV-436 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Dan Washusen > > JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 but it needs > connector-1.5. If you attempt to use the current POM you'll get a > "java.lang.NoClassDefFoundError: javax/resource/spi/XATerminator" 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] Closed: (MAVENUPLOAD-1050) content repository API 1.0 and 1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1050?page=all ] Carlos Sanchez closed MAVENUPLOAD-1050. --- Assignee: Carlos Sanchez Resolution: Fixed uploaded bundles > content repository API 1.0 and 1.0.1 > > > Key: MAVENUPLOAD-1050 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1050 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > > version 1.0 bundle: > http://maven-taglib.sourceforge.net/bundles/jcr-1.0-bundle.jar > version 1.0.1 bundle: > http://maven-taglib.sourceforge.net/bundles/jcr-1.0.1-bundle.jar -- 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: (MAVENUPLOAD-1085) Upload drools:drools-compiler:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1085?page=all ] Carlos Sanchez reopened MAVENUPLOAD-1085: - Assignee: (was: Carlos Sanchez) > Upload drools:drools-compiler:3.0.4 to ibiblio > -- > > Key: MAVENUPLOAD-1085 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1085 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/drools-compiler-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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: (MAVENUPLOAD-1088) Upload drools:drools-decisiontables:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1088?page=all ] Carlos Sanchez reopened MAVENUPLOAD-1088: - Assignee: (was: Carlos Sanchez) > Upload drools:drools-decisiontables:3.0.4 to ibiblio > > > Key: MAVENUPLOAD-1088 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1088 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/drools-decisiontables-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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: (MAVENUPLOAD-1084) Upload drools:drools-core:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1084?page=all ] Carlos Sanchez reopened MAVENUPLOAD-1084: - Assignee: (was: Carlos Sanchez) > Upload drools:drools-core:3.0.4 to ibiblio > -- > > Key: MAVENUPLOAD-1084 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1084 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/drools-core-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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-1086) Upload org.jcp:jsr94:1.1 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1086?page=all ] Carlos Sanchez closed MAVENUPLOAD-1086. --- Assignee: Carlos Sanchez Resolution: Won't Fix License desn't seem to allow redistribution > Upload org.jcp:jsr94:1.1 to ibiblio > --- > > Key: MAVENUPLOAD-1086 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1086 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/jsr94-1.1-bundle.jar > http://jcp.org/en/jsr/detail?id=94 -- 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-1085) Upload drools:drools-compiler:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1085?page=all ] Carlos Sanchez closed MAVENUPLOAD-1085. --- Assignee: Carlos Sanchez Resolution: Fixed next time please put all bundle urls in only one issue > Upload drools:drools-compiler:3.0.4 to ibiblio > -- > > Key: MAVENUPLOAD-1085 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1085 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/drools-compiler-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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-1084) Upload drools:drools-core:3.0.4 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1084?page=all ] Carlos Sanchez closed MAVENUPLOAD-1084. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload drools:drools-core:3.0.4 to ibiblio > -- > > Key: MAVENUPLOAD-1084 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1084 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/drools-core-3.0.4-bundle.jar > http://www.jboss.com/products/rules > JBoss Rules provides an open source and standards-based business rules engine > that enables easy business policy access, change and management. JBoss Rules > is a fast and highly efficient rules engine that makes it easy for a business > analyst or auditor to view your business rules as encoded in your IT > application infrastructure to verify that the encoded rules indeed implement > the documented business policies. JBoss Rules also supports a variety of > language and decision table inputs, making it easy to quickly modify your > business policies to respond to opportunities and competitive threats. -- 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: (MAVENUPLOAD-1035) POM for wstx-asl-2.9.3 is missing
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1035?page=all ] Jochen Wiedmann updated MAVENUPLOAD-1035: - Attachment: wstx-asl-2.9.3.jar Uploading a new POM with license and dependency informations. > POM for wstx-asl-2.9.3 is missing > - > > Key: MAVENUPLOAD-1035 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1035 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Jochen Wiedmann > Attachments: wstx-asl-2.9.3.jar > > > The directory > http://repo1.maven.org/maven2/woodstox/wstx-asl/2.9.3 > does not contain a POM. This jar file is referenced by popular applications > like Axis2-1.0. -- 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-1076) XStream 1.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1076?page=all ] Carlos Sanchez closed MAVENUPLOAD-1076. --- Assignee: Carlos Sanchez Resolution: Fixed Syncing right now > XStream 1.2 > --- > > Key: MAVENUPLOAD-1076 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1076 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joerg Schaible > Assigned To: Carlos Sanchez > > Please sync Codehaus repo! What's the proper task for such a request? I > already tried on the dev list two days ago. -- 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-1079) serp
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1079?page=all ] Carlos Sanchez closed MAVENUPLOAD-1079. --- Assignee: Carlos Sanchez Resolution: Fixed You can get your repo synced easily, see end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html and http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/bin/m2-sync/conf/ > serp > > > Key: MAVENUPLOAD-1079 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1079 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Prud'hommeaux > Assigned To: Carlos Sanchez > > Serp is a popular open source framework for manipulating Java bytecode. -- 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-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=comments#action_73237 ] Carlos Sanchez commented on MAVENUPLOAD-1078: - there's a snapshot dependency that can't be there > subethasmtp 1.0.3 bundles > - > > Key: MAVENUPLOAD-1078 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > > subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc > plus an additional artifact for the jdk14 compatible version with a "java14" > classifier > http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar > http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar > subethasmtp-parent: only contains the parent pom > http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-bundle.jar -- 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-1077) Logback 0.2.5 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1077?page=comments#action_73235 ] Carlos Sanchez commented on MAVENUPLOAD-1077: - you need to provide the parent pom what a bout setting your repo and we'll sync from it? see end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html and http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/bin/m2-sync/conf/ > Logback 0.2.5 upload request > > > Key: MAVENUPLOAD-1077 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1077 > Project: maven-upload-requests > Issue Type: Task >Reporter: Sebastien Pennec > Attachments: logback-access-0.2.5-bundle.jar, > logback-classic-0.2.5-bundle.jar, logback-core-0.2.5-bundle.jar > > > The logback project recently released version 0.2.5 of all three modules. > Please kindly add the attached files to ibiblio's maven repository. -- 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-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=all ] Carlos Sanchez closed MEV-413. -- Assignee: Carlos Sanchez Resolution: Won't Fix > Jaxen has unnecessary and unexpected dependencies (which cause problems with > JDK 1.5) > - > > Key: MEV-413 > URL: http://jira.codehaus.org/browse/MEV-413 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Jimisola Laursen > Assigned To: Carlos Sanchez > > The pom > (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) > has dependencies on domj, jdom, xom, xerces:xercesImpl and > xerces:xmlParserAPIs (see below). > I can't see why any of these dependencies are necessary - especially not the > dependency on xerces. A slimmed down verson of Xerces is included with JDK > 1.5 and adding an addition Xerces in the classpath caused some major > headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen > 1.1-beta-9 has. > > > dom4j > dom4j > 1.6.1 > > > jdom > jdom > 1.0 > > > xerces > xmlParserAPIs > 2.6.2 > > > xerces > xercesImpl > 2.6.2 > > > xom > xom > 1.0b3 > > -- 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-1035) POM for wstx-asl-2.9.3 is missing
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1035?page=all ] Carlos Sanchez closed MAVENUPLOAD-1035. --- Assignee: Carlos Sanchez Resolution: Fixed > POM for wstx-asl-2.9.3 is missing > - > > Key: MAVENUPLOAD-1035 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1035 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Jochen Wiedmann > Assigned To: Carlos Sanchez > Attachments: wstx-asl-2.9.3.jar > > > The directory > http://repo1.maven.org/maven2/woodstox/wstx-asl/2.9.3 > does not contain a POM. This jar file is referenced by popular applications > like Axis2-1.0. -- 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-1080) Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1080?page=comments#action_73248 ] Carlos Sanchez commented on MAVENUPLOAD-1080: - missing minimal info, see http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio > > > Key: MAVENUPLOAD-1080 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1080 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/core-3.2.0.666-bundle.jar > http://www.eclipse.org/jdt/ -- 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-1082) Upload org.apache.jakarta.commons:commons-jci-janino:2.4.3 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1082?page=all ] Carlos Sanchez closed MAVENUPLOAD-1082. --- Assignee: Carlos Sanchez Resolution: Won't Fix apache artifacts must be upload by each apache project, anyway this doesn't look like an apache artifact and more like an eclipse one > Upload org.apache.jakarta.commons:commons-jci-janino:2.4.3 to ibiblio > - > > Key: MAVENUPLOAD-1082 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1082 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > Assigned To: Carlos Sanchez > > http://www.mattwhitlock.com/commons-jci-janino-2.4.3-bundle.jar > http://jakarta.apache.org/commons/sandbox/jci/ -- 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-1089) JExcelApi 2.6 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1089?page=comments#action_73239 ] Carlos Sanchez commented on MAVENUPLOAD-1089: - missing minimal info listed in http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > JExcelApi 2.6 Upload > > > Key: MAVENUPLOAD-1089 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu > > http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar > http://jexcelapi.sourceforge.net/ > JasperReports relies on this version of JExcelApi, so we need it uploaded to > the Maven repositories. > This is why it is me who uploads the bundle, although I'm not a JExcelApi > developer. -- 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-1074) saxon-jdom 7.9.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1074?page=all ] Carlos Sanchez closed MAVENUPLOAD-1074. --- Assignee: Carlos Sanchez Resolution: Fixed > saxon-jdom 7.9.1 > > > Key: MAVENUPLOAD-1074 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1074 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jorg Heymans > Assigned To: Carlos Sanchez > -- 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-1075) saxon-sql 7.9.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1075?page=all ] Carlos Sanchez closed MAVENUPLOAD-1075. --- Assignee: Carlos Sanchez Resolution: Fixed > saxon-sql 7.9.1 > --- > > Key: MAVENUPLOAD-1075 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1075 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jorg Heymans > Assigned To: Carlos Sanchez > -- 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-1073) saxon 7.9.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1073?page=all ] Carlos Sanchez closed MAVENUPLOAD-1073. --- Assignee: Carlos Sanchez Resolution: Fixed Next time pleas paste all bundle urls in only one issue > saxon 7.9.1 > --- > > Key: MAVENUPLOAD-1073 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1073 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jorg Heymans > Assigned To: Carlos Sanchez > > please upload saxon 7.9.1 to ibiblio and mirrors. -- 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-1072) Please upload ldaptemplate-1.0.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1072?page=all ] Carlos Sanchez closed MAVENUPLOAD-1072. --- Assignee: Carlos Sanchez Resolution: Won't Fix It IS there http://www.ibiblio.org/maven2/net/sf/ldaptemplate/ldaptemplate/1.0.1/ > Please upload ldaptemplate-1.0.1 > > > Key: MAVENUPLOAD-1072 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1072 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ulrik Sandberg > Assigned To: Carlos Sanchez > > LdapTemplate is a Java framework to simplify LDAP operations, based on the > pattern of Spring's JdbcTemplate. It has become quite popular, with downloads > now reaching 500-600 per month. > The framework has recently been added as a Spring sub-project, and future > releases will be under the name Spring LDAP. > A previous upload request (MAVENUPLOAD-1070) was denied because 1.0.1 > supposedly was already in ibiblio, but that does not seem to be the case. The > pom and the license files are there, but no jar and no 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73260 ] Jian Wu commented on SUREFIRE-31: - I tried to download surefire-junit4.zip. When I tried to run "mvn install" from unziped surefire-junit4 directory. I got the following exceptions: [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.surefire ArtifactId: surefire-providers Version: 2.0-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.maven.surefire:surefire-providers:pom:2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache .maven.surefire:surefire-providers for project: null:surefire-junit4:jar:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.project.ProjectBuildingException: Cannot find parent : org.apache.maven.surefire:surefire-providers for project: null:surefire-junit4 :jar:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.ma ven.surefire:surefire-providers' not found in repository: Unable to download the artifact from any repository org.apache.maven.surefire:surefire-providers:pom:2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1157) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.maven.surefire:surefire-providers:pom:2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:467) ... 18 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl oad the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def aultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:124) ... 20 more [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Thu Aug 24 14:27:06 PDT 2006 [INFO] Final Memory: 1M/2M [INFO] Could you please tell me which Maven2 Repository I should add to make it work? Thanks a lot! Jian > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.co
[jira] Commented: (MECLIPSE-132) "Class not found" when run/debug JUnit tests
[ http://jira.codehaus.org/browse/MECLIPSE-132?page=comments#action_73258 ] Jimisola Laursen commented on MECLIPSE-132: --- Eugene or other person in the Maven 2.x Eclipse Plugin team, are you not experiencing this problem? I see it quite often and it's causing a lot of head-ache. I would gladly provide more information if I know what to look for. > "Class not found" when run/debug JUnit tests > > > Key: MECLIPSE-132 > URL: http://jira.codehaus.org/browse/MECLIPSE-132 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: dependency resolution > Environment: gentoo linux 2006, kernel 2.6, sun-jdk-1.5.0.06, maven > 2.0.4, eclipse sdk 3.2, myeclipse 5 m2 >Reporter: Diego Ballve > > This is for the behavior described in > http://www.nabble.com/Keep-getting-%22Class-not-found%22-when-running-debugging-JUnit-tests-tf1851758.html#a5442440 > You get "Class not found" when running/debuging JUnit tests. > For me it happened when I was importing another project and its dependencies > (both m2 projects). > Clean compile works fine, problem is with run. > The workaround to get it working is: > In the project containing your tests, edit Java Build Path | Order and > Export: Make sure M2 Dependencies appears BEFORE JRE System Library. > Thanks, > Diego -- 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-120) ModuleSet/Binaries include/exclude not implemented
[ http://jira.codehaus.org/browse/MASSEMBLY-120?page=comments#action_73224 ] Simon Goodall commented on MASSEMBLY-120: - The fix is in the current snapshot version. > ModuleSet/Binaries include/exclude not implemented > -- > > Key: MASSEMBLY-120 > URL: http://jira.codehaus.org/browse/MASSEMBLY-120 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: linux (fedora core 5) / maven 2.0.4 / java 1.5 >Reporter: Simon Goodall > Assigned To: John Casey > > The binaries section of moduleSet has an include / exclude section defined, > but it is not implemented. Currently a module can only include all or none of > its dependencies (through the includeDependencies tag). There is no selective > inclusion/exclusion of dependencies. -- 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-1090) Upload of Maven Docbkx Plugin
Upload of Maven Docbkx Plugin - Key: MAVENUPLOAD-1090 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1090 Project: maven-upload-requests Issue Type: Task Reporter: Wilfred Springer http://www.agilejava.com/downloads/docbkx-builder-maven-plugin-0.8-bundle.jar http://www.agilejava.com/downloads/docbkx-maven-base-0.8-bundle.jar http://www.agilejava.com/downloads/docbkx-maven-plugin-1.69.1.7-bundle.jar An alternative for the Maven DocBook plugin found at mojo.codehaus.org. -- 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] Moved: (MWAR-72) Need ability to protect (or exclude) resource from being destroyed during war overlay.
[ http://jira.codehaus.org/browse/MWAR-72?page=all ]
Joakim Erdfelt moved MPWAR-64 to MWAR-72:
-
Affects Version/s: (was: 1.6.2)
2.0.1
Workflow: Maven New (was: jira)
Key: MWAR-72 (was: MPWAR-64)
Project: Maven 2.x War Plugin (was: maven-war-plugin)
> Need ability to protect (or exclude) resource from being destroyed during war
> overlay.
> --
>
> Key: MWAR-72
> URL: http://jira.codehaus.org/browse/MWAR-72
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Joakim Erdfelt
>
> If you have a template war TEMPLATE.war that is used to overlay the current
> project war CURRENT.war, and there are values in the CURRENT.war that should
> never be overlaid, a mechanism needs to exist to protect those resources.
> Example:
> template.war uses xwork - /WEB-INF/classes/xwork.xml
> current.war also uses xwork.
> when you overlay template.war onto current.war you want to prevent
> /WEB-INF/classes/xwork.xml from being overwritten.
> desired.
> {noformat}
>
> org.apache.maven.plugin
> maven-war-plugin
>
>
>
> /WEB-INF
>
> classes/xwork.xml
>
>
>
>
>
> {noformat}
> You can use the maven-shared/file-management FileSet implementation to
> perform this (see maven-clean-plugin) for example usage.
--
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: (MPWAR-64) Need ability to protect (or exclude) resource from being destroyed during war overlay.
Need ability to protect (or exclude) resource from being destroyed during war
overlay.
--
Key: MPWAR-64
URL: http://jira.codehaus.org/browse/MPWAR-64
Project: maven-war-plugin
Issue Type: Bug
Affects Versions: 1.6.2
Reporter: Joakim Erdfelt
If you have a template war TEMPLATE.war that is used to overlay the current
project war CURRENT.war, and there are values in the CURRENT.war that should
never be overlaid, a mechanism needs to exist to protect those resources.
Example:
template.war uses xwork - /WEB-INF/classes/xwork.xml
current.war also uses xwork.
when you overlay template.war onto current.war you want to prevent
/WEB-INF/classes/xwork.xml from being overwritten.
desired.
{noformat}
org.apache.maven.plugin
maven-war-plugin
/WEB-INF
classes/xwork.xml
{noformat}
You can use the maven-shared/file-management FileSet implementation to perform
this (see maven-clean-plugin) for example usage.
--
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-2522) Regression for the Eclipse codestyle
[ http://jira.codehaus.org/browse/MNG-2522?page=all ]
Vincent Siveton updated MNG-2522:
-
Attachment: test-codestyle.zip
small test case
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch, test-codestyle.zip
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MNG-2522) Regression for the Eclipse codestyle
[ http://jira.codehaus.org/browse/MNG-2522?page=comments#action_73211 ]
Vincent Siveton commented on MNG-2522:
--
Weird... I have just tried with several Eclipse 3.2 distribution (not found M7)
and the codestyle (rev434493) was not rendered properly.
{noformat}
public class Something extends SomethingElse implements SomeInterface
{
}
{noformat}
Tested on:
S-3.2M6-200603312000/ 03-Apr-2006 13:29
R-3.2-200606291905/ 11-Jul-2006 13:02
S-3.2RC7-200606021317/ 09-Jun-2006 12:52
S-3.2M5-200602171115/ 17-Feb-2006 17:37
(http://mirror.uta.edu/eclipse/eclipse/downloads/drops/)
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch, test-codestyle.zip
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MNG-2473) Improve Site Structuring
[ http://jira.codehaus.org/browse/MNG-2473?page=comments#action_73208 ] Joakim Erdfelt commented on MNG-2473: - Just a subtle request. Since some of the new nav items are now 2 lines long, how about some visual guidance on the seperation of the expanded menu items. Example: http://joakim.erdfelt.com/maven-site/index-new-nav-items-w-top-right-quicklinks.html > Improve Site Structuring > > > Key: MNG-2473 > URL: http://jira.codehaus.org/browse/MNG-2473 > Project: Maven 2 > Issue Type: Task > Components: Documentation: General >Reporter: Marvin King > Assigned To: Marvin King > Attachments: index[new_nav_items].html, > index[new_nav_items_w_top_right_quicklinks].html, > MNG-2473-site-[new_nav_items].patch, > MNG-2473-site-[new_nav_items_w_top_right_quicklinks].patch > > Time Spent: 6 hours > Remaining Estimate: 0 minutes > > See my proposal here: > http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/[EMAIL > PROTECTED] > See also: > http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL > PROTECTED]> > http://mail-archives.apache.org/mod_mbox/maven-dev/200606.mbox/<[EMAIL > PROTECTED]> > Key to this is particularly changing the content of the front page, as well > as the navigation. -- 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: (SCM-223) VSS add command
[ http://jira.codehaus.org/browse/SCM-223?page=comments#action_73207 ] Emmanuel Venisse commented on SCM-223: -- I don't have time to review it now > VSS add command > --- > > Key: SCM-223 > URL: http://jira.codehaus.org/browse/SCM-223 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-vss >Reporter: Thorsten Riek > Attachments: SCM-223-02-maven-scm-provider-vss.patch, > SCM-223-03-maven-scm-provider-vss.patch, SCM-223-maven-scm-provider-vss.patch > > > Some minor changes and VSS add command implementation. -- 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: (MSITE-138) site:stage does not create xref
[ http://jira.codehaus.org/browse/MSITE-138?page=comments#action_73206 ] Jörg Hohwiller commented on MSITE-138: -- Since the snapshot repro seems to be quire old, I checked out the trunk and tried to build the latest version. For the naive way I got lost when I was told that I need maven 2.0.5 to continue. Then I started to hack locally but got lost from maven-site-plugin -> maven-reporting-api -> doxia-sink-api -> ... Seems that you updated the complete dependency tree ;) Is there are hotfix possible without upgrading to maven-reporting-api 2.0 to 2.1(-SNAPSHOT) and all caused implications. On the other hand: Will the new stuff be released within the next couple of weeks (or this year at all)? Or will a SNAPSHOT be available at maven-snapshot-repository in the next future? I still have NOT understood what the actual problem was, but it seems to be a tiny bug since it works properly with mvn site... > site:stage does not create xref > --- > > Key: MSITE-138 > URL: http://jira.codehaus.org/browse/MSITE-138 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Jorg Heymans > Assigned To: Vincent Siveton > Fix For: 2.0 > > > as reported here : > http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.user/40178 > the xref and test-xref dirs both have an empty index.html after the site is > staged. -- 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: (MNG-2528) updatePolicy "always" does not work for repositories with "releases", at least not for transitive dependencies
updatePolicy "always" does not work for repositories with "releases", at least not for transitive dependencies -- Key: MNG-2528 URL: http://jira.codehaus.org/browse/MNG-2528 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Arne Degenring Released versions normally should be final. Once deployed, they should not be upgraded. That's what snapshot versions are for. Anyway, Maven *does* allow to overwrite an existing version in the repository by re-deploying it. Therefore, to make builds repeatable and reproducable, Maven should check for updates even of released versions, not only snapshot versions. I tried to use the following setting: true always ... My project A has a dependency to version 5.0-SNAPSHOT of a JAR B. That JAR B has a dependency to version 1.6 of another JAR C. In my local repository there's an outdated version 1.6 of JAR C (i.e. version 1.6 has been redeployed after a bug has been found). The problem is: During my build of project A Maven is looking for an update of JAR B, but NOT of JAR C. This problem was originally discussed on http://www.nabble.com/-m2--Updates-of-transitive-dependencies-not-working--tf2158398.html -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
When proxy is used by maven1artifact are stored in managed repo using legacy layout. Key: MRM-155 URL: http://jira.codehaus.org/browse/MRM-155 Project: Maven Repository Manager Issue Type: Bug Components: remote proxy Reporter: nicolas de loof Attachments: DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the artifact is stored using legacy layout (maven1 path). When a maven2 client asks for it, the artifact is downloaded a second time and stored using maven2 layout. This may produce lot's of duplicates in the managed repo. request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 -> servletapi\jars\servletapi-2.3.jar request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " -> servletapi\servletapi\2.3\servletapi-2.3.jar -- 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: (MNG-2522) Regression for the Eclipse codestyle
[ http://jira.codehaus.org/browse/MNG-2522?page=comments#action_73204 ]
Kenney Westerhof commented on MNG-2522:
---
Using the current version of the codestyle from svn it renders correctly as
public class Something
extends SomethingElse
implements SomeInterface
{
}
(using 3.2-M7)
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_73203 ] Eugene Kuleshov commented on MNGECLIPSE-59: --- Marek, please provide exact steps to reproduce. Thanks. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=all ]
Eugene Kuleshov updated MNGECLIPSE-189:
---
Priority: Trivial (was: Major)
Please attach an example project that can be used to reproduce this issue.
Thanks.
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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: (MNGECLIPSE-188) [ERROR] mojo-execute : compiler:compile
[ http://jira.codehaus.org/browse/MNGECLIPSE-188?page=comments#action_73201
]
Eugene Kuleshov commented on MNGECLIPSE-188:
Please check that you running Maven with JDK and JRE.
> [ERROR] mojo-execute : compiler:compile
>
>
> Key: MNGECLIPSE-188
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-188
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
> Components: Maven Launcher, POM Editor
>Affects Versions: 0.0.5
> Environment: windows xp, eclipse 3.2, jdk 1.5_05
>Reporter: Stefaan Delanghe
> Assigned To: Eugene Kuleshov
>Priority: Blocker
> Attachments: startup.zip
>
>
> After launching mvn clean install on this pom file i get this error message.
> I looked at the forums before posting this issue, but it seems the problem is
> not
> related to that. I could launched another pom file which only varies in
> depencies and project defintion and that works just fine.
> Could the problem be in my pom file definition or am i missing something
> else?
> WARN] Unable to get resource from repository central
> (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Building backend
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] clean:clean
> [INFO] Deleting directory
> D:\Development\workspace\Start\startup\backend\target
> [INFO] Deleting directory
> D:\Development\workspace\Start\startup\backend\target\classes
> [INFO] Deleting directory
> D:\Development\workspace\Start\startup\backend\target\test-classes
> [INFO] resources:resources
> [INFO] Using default encoding to copy filtered resources.
> [INFO] compiler:compile
> Compiling 10 source files to
> D:\Development\workspace\Start\startup\backend\target\classes
> [ERROR] mojo-execute : compiler:compile
> Diagnosis: Compilation failure
> FATAL ERROR: Error executing Maven for a project
> [ERROR] project-execute : visionit:backend:jar:0.1 ( task-segment: [clean,
> install] )
> Diagnosis: Compilation failure
> FATAL ERROR: Error executing Maven for a project
> org.apache.maven.BuildFailureException: Compilation failure
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413)
> at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68)
> Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation
> failure
> at
> org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505)
> at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
> ... 8 more
> Here is my pom file that gives this error on execution of mvn clean install:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> visionit
> backend
> jar
> 0.1
> backend
>
> the backend development of the application
>
>
>
> org.springframework
> spring
> 1.2.8
> test
>
>
> org.hibernate
> hibernate
> 3.1.3
> test
>
>
>
> src/main/java
> src/main/scripts
> src/test/java
> target
> target/classes
> target/test-classes
> ${artifactId}-${version}
>
>
> src/main/resources
>
[jira] Closed: (MCLEAN-11) clean plugin unit test
[ http://jira.codehaus.org/browse/MCLEAN-11?page=all ] Joakim Erdfelt closed MCLEAN-11. Resolution: Fixed Fix Version/s: 2.1.1 Issue has been resolved / fixed already. > clean plugin unit test > -- > > Key: MCLEAN-11 > URL: http://jira.codehaus.org/browse/MCLEAN-11 > Project: Maven 2.x Clean Plugin > Issue Type: Improvement >Reporter: Jesse McConnell >Priority: Minor > Fix For: 2.1.1 > > Attachments: clean-plugin-normal-unit-test.patch, > maven-clean-plugin-plexify.jar > > > straight forward unit test for clean plugin > also added the version that was refactored to use plexus and convert the > CleanMojo to more of an adapter onto a more easily tested plugin, or at least > elegantly tested plugin > adding this jira issue to hold this stuff and I'll link it in the email > thread on dev -- 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: (MRM-154) DigestUtils fails to verify checksum from ibiblio
DigestUtils fails to verify checksum from ibiblio
-
Key: MRM-154
URL: http://jira.codehaus.org/browse/MRM-154
Project: Maven Repository Manager
Issue Type: Bug
Reporter: nicolas de loof
Attachments: DigestUtils.java.patch
Downloading servletapi-24.pom fails.
DigestUtils.cleanChecksum check for filename in remote checksum file to be same
as local, but tets is inverted :
String filename = m.group( 2 );
if ( !path.endsWith( filename ) )
{
throw new DigesterException( "Supplied checksum does not
match checksum pattern" );
}
filename =
"/home/projects/maven/repository-staging/to-ibiblio/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom"
path = "servletapi-2.4.pom".
Patch provided to test if ( !path.endsWith( filename ) )
--
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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
JUnit runner does not process resource filters before running
-
Key: MNGECLIPSE-189
URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
Project: Maven 2.x Extension for Eclipse
Issue Type: Bug
Affects Versions: 0.0.9
Environment: Eclipse 3.1.2 Linux
Reporter: Jonathan Share
Assigned To: Eugene Kuleshov
I have a project that uses a resource filter to set the path to some files
depending on what platform the developer is on. Using maven on the command line
this is processed correctly and the Unit tests pass. However, I wish to use the
JUnit runner within eclipse however as my resources do not get filtered before
the tests try to load them I get exceptions creating URL objects with
${news.image.url} in them.
Desired behaviour
===
This plugin should provide a launcher for the junit runner that first runs the
process-resources (apologies if this is wrong, writing from memory here) target
and ensure the classpath is configured correctly so that the non processed
resources are not available to the JUnit runner before running the JUnit tests.
--
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-1089) JExcelApi 2.6 Upload
JExcelApi 2.6 Upload Key: MAVENUPLOAD-1089 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar http://jexcelapi.sourceforge.net/ JasperReports relies on this version of JExcelApi, so we need it uploaded to the Maven repositories. This is why it is me who uploads the bundle, although I'm not a JExcelApi developer. -- 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: (MNGECLIPSE-188) [ERROR] mojo-execute : compiler:compile
[ERROR] mojo-execute : compiler:compile
Key: MNGECLIPSE-188
URL: http://jira.codehaus.org/browse/MNGECLIPSE-188
Project: Maven 2.x Extension for Eclipse
Issue Type: Bug
Components: Maven Launcher, POM Editor
Affects Versions: 0.0.5
Environment: windows xp, eclipse 3.2, jdk 1.5_05
Reporter: Stefaan Delanghe
Assigned To: Eugene Kuleshov
Priority: Blocker
Attachments: startup.zip
After launching mvn clean install on this pom file i get this error message. I
looked at the forums before posting this issue, but it seems the problem is not
related to that. I could launched another pom file which only varies in
depencies and project defintion and that works just fine.
Could the problem be in my pom file definition or am i missing something else?
WARN] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO]
[INFO] Building backend
[INFO]task-segment: [clean, install]
[INFO]
[INFO] clean:clean
[INFO] Deleting directory D:\Development\workspace\Start\startup\backend\target
[INFO] Deleting directory
D:\Development\workspace\Start\startup\backend\target\classes
[INFO] Deleting directory
D:\Development\workspace\Start\startup\backend\target\test-classes
[INFO] resources:resources
[INFO] Using default encoding to copy filtered resources.
[INFO] compiler:compile
Compiling 10 source files to
D:\Development\workspace\Start\startup\backend\target\classes
[ERROR] mojo-execute : compiler:compile
Diagnosis: Compilation failure
FATAL ERROR: Error executing Maven for a project
[ERROR] project-execute : visionit:backend:jar:0.1 ( task-segment: [clean,
install] )
Diagnosis: Compilation failure
FATAL ERROR: Error executing Maven for a project
org.apache.maven.BuildFailureException: Compilation failure
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413)
at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation
failure
at
org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
... 8 more
Here is my pom file that gives this error on execution of mvn clean install:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
visionit
backend
jar
0.1
backend
the backend development of the application
org.springframework
spring
1.2.8
test
org.hibernate
hibernate
3.1.3
test
src/main/java
src/main/scripts
src/test/java
target
target/classes
target/test-classes
${artifactId}-${version}
src/main/resources
src/test/resources
compile
visionit
utils
0.1
[jira] Commented: (SCM-223) VSS add command
[ http://jira.codehaus.org/browse/SCM-223?page=comments#action_73189 ] Thorsten Riek commented on SCM-223: --- Is something wrong with the patch? > VSS add command > --- > > Key: SCM-223 > URL: http://jira.codehaus.org/browse/SCM-223 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-vss >Reporter: Thorsten Riek > Attachments: SCM-223-02-maven-scm-provider-vss.patch, > SCM-223-03-maven-scm-provider-vss.patch, SCM-223-maven-scm-provider-vss.patch > > > Some minor changes and VSS add command implementation. -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_73187 ] Marek Bieganski commented on MNGECLIPSE-59: --- There are still problems on open/close or checkout/delete projects declared as dependencies in other project's pom. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (CONTINUUM-800) Use maven-user project for user management
[ http://jira.codehaus.org/browse/CONTINUUM-800?page=all ] Henry S. Isidro updated CONTINUUM-800: -- Attachment: CONTINUUM-800-continuum-acegi-branch.patch File Attached: CONTINUUM-800-continuum-acegi-branch.patch This patch makes continuum use maven-user. ContinuumUser now extends the classes in maven-user-model. > Use maven-user project for user management > -- > > Key: CONTINUUM-800 > URL: http://jira.codehaus.org/browse/CONTINUUM-800 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Attachments: CONTINUUM-800-continuum-acegi-branch.patch, > CONTINUUM-800-continuum-webapp.patch, > CONTINUUM-800-maven-user-model-testing.patch, > CONTINUUM-800-maven-user-model-update-2.patch, > CONTINUUM-800-maven-user-webapp-update-2.patch, > CONTINUUM-800-maven-user-webapp.patch, CONTINUUM-800-maven-user.patch > > > Added a first version of user management in > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-user > We have to move user code from Continuum there and use it instead -- 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: (MJAVADOC-72) Aggregating javadocs doesn't work
[ http://jira.codehaus.org/browse/MJAVADOC-72?page=comments#action_73179 ] Rohnny Moland (JIRA) commented on MJAVADOC-72: -- I tried the patch from 20 august, and that seems to fix the problem. So I think this bug could be closed now. > Aggregating javadocs doesn't work > - > > Key: MJAVADOC-72 > URL: http://jira.codehaus.org/browse/MJAVADOC-72 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: WinXP SP2 > cygwin 1.5.19 > maven 2.0.4 > jdk 1.5.0_06 > javadoc-plugin 2.0 final > latest released plugins >Reporter: Bugittaa Pahasti > Attachments: MJAVADOC-72.patch > > > When I define true to javadoc plugin configuration in > parent pom, javadoc generation doesn't work from the parent (all other > configuration options are default). If run under individual components, > javadoc is generated without problems. It seems that the child dependencies > aren't resolved: > Embedded error: Exit code: 1 - > c:/code/apps/project/common/src/main/java/com/company/AbstractLogEnabled.java:3: > package org.apache.log4j does not exist > import org.apache.log4j.Logger; > c:/code/apps/component/common-test/src/main/java/com/company/unittest/AbstractDatasourceEnabledTestCase.java:11: > package org.apache.commons.dbcp does not exist > import org.apache.commons.dbcp.BasicDataSource; > And lot more similar errors. > Additionally, there are a huge number of ClassCastExceptions from javadoc. > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > at > com.sun.tools.doclets.internal.toolkit.util.Util.isDeprecated(Util.java:804) > at > com.sun.tools.doclets.formats.html.TagletWriterImpl.deprecatedTagOutput(TagletWriterImpl.java:85) > at > com.sun.tools.doclets.internal.toolkit.taglets.DeprecatedTaglet.getTagletOutput(DeprecatedTaglet.java:40) > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeDeprecated(MethodWriterImpl.java:166) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildDeprecationInfo(MethodBuilder.java:183) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildMethodDoc(MethodBuilder.java:150) > at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.invokeMethod(MethodBuilder.java:109) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractMemberBuilder.build(AbstractMemberBuilder.java:56) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildMethodDetails(ClassBuilder.java:322) > at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:124) > at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.invokeMethod(ClassBuilder.java:101) > at > com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:90) > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:108) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:155) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:177) > at > com.sun.tools.doclets.internal.toolkit.Abs
[jira] Created: (MINSTALL-32) classifier does not work on install:install-file, default artifact overwritten
classifier does not work on install:install-file, default artifact overwritten -- Key: MINSTALL-32 URL: http://jira.codehaus.org/browse/MINSTALL-32 Project: Maven 2.x Install Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Simon Gunzenreiner It would be very useful to be able to use the a -Dclassifer argument to the install:install-file plugin. Although the documentation does not mention that the use of "classifier" is supported, the InstallFileMojo let's assume so - because it uses the "classifier". Still though if install:insta--file is used in the following way: mvn install:install-file -DgeneratePom=true -Dpackaging=jar -DgroupId=myGroupId -Dversion=myVersino -DartifactId=myArtifactId -Dclassifier=sources -Dfile=myArtifactId-myVersion-sources.jar the default (jar) artifact is replaced with the sources artifact in the repository. -- 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-143) classifier automatically appended to artifactId in
[ http://jira.codehaus.org/browse/MASSEMBLY-143?page=comments#action_73165
]
Simon Gunzenreiner commented on MASSEMBLY-143:
--
By the way, even if ${classifier} is used in the mapping expression, it is even
added twice to the resulting path - It should be either added automatically
(not favorable), or only added if ${classifier} variable is used.
> classifier automatically appended to artifactId in
> --
>
> Key: MASSEMBLY-143
> URL: http://jira.codehaus.org/browse/MASSEMBLY-143
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Simon Gunzenreiner
>
> There is no way to omit the classifier variable in ,
> because if left out, the artifact classifier is automatically appended to the
> artifactId. In my use case I would like to replace the classifier with a
> constant value (after including only specific classifiers) - but I cant,
> because it's automatically added.
--
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-143) classifier automatically appended to artifactId in
classifier automatically appended to artifactId in -- Key: MASSEMBLY-143 URL: http://jira.codehaus.org/browse/MASSEMBLY-143 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Simon Gunzenreiner There is no way to omit the classifier variable in , because if left out, the artifact classifier is automatically appended to the artifactId. In my use case I would like to replace the classifier with a constant value (after including only specific classifiers) - but I cant, because it's automatically added. -- 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
