Re: Maven and Fedora
On 12/14/06, Deepak Bhole [EMAIL PROTECTED] wrote: Why is offline behaviour useful? It is just the way Fedora does things to ensure that everything is traceable. It is to ensure that the entire application is built ground up from sources. All of the System installed jars that I am referring to above, are jars that come from packages we built into Fedora, which would have been built from source. so you need all jars that Maven depends on to be built from sources, right? it's just that you already have the most used ones built already (eg. xerces) and only need the ones Fedora hasn't built yet (eg. plexus). This is just the build step for inclusion in Fedora and ensure sources match binaries, after maven is built users will do as usual and first time they call mvn all those dependencies will be downloaded from the repo instead of using the Fedora provided ones. did I get it right? -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Future of the Release Process.
On Thu, December 14, 2006 1:46 am, Joakim Erdfelt wrote: Disclaimer: I am not attempting to set policy, just to get discussion going, document it, and work towards the ideal toolchain that make the future of apache releases smooth, consistent, and resilient Desired End Goal: This discussion will revolve around the apache process for official releases of projects. [snip lots and lots of barriers to release] Although I can see the desire to enforce compliance on policy, I think adopting barriers to release like this will cause the projects to just never be released, making an already bad problem worse. There is another showstopper to this: One of the key provisions of releasing artifacts at the ASF is that a release cannot be vetoed. The thinking is that our code in SVN should always be policy compliant, meaning that a release at any time should never be a problem. What will probably work a lot better is for compliance to be enforced at the source level, and here a compliance plugin hooked into the test phase can check for all the various things like license headers on files etc as required by the project. So rather than chase people around months after code was committed to bring it into compliance, the developer of a plugin can get immediate feedback while they are developing to say that files X, Y and Z are non compliant and need to be fixed. Extra points if the plugin can auto-fix some of the issues. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Future of the Release Process.
On 12/14/06, Graham Leggett [EMAIL PROTECTED] wrote: On Thu, December 14, 2006 1:46 am, Joakim Erdfelt wrote: Disclaimer: I am not attempting to set policy, just to get discussion going, document it, and work towards the ideal toolchain that make the future of apache releases smooth, consistent, and resilient Desired End Goal: This discussion will revolve around the apache process for official releases of projects. [snip lots and lots of barriers to release] Although I can see the desire to enforce compliance on policy, I think adopting barriers to release like this will cause the projects to just never be released, making an already bad problem worse. There is another showstopper to this: One of the key provisions of releasing artifacts at the ASF is that a release cannot be vetoed. The thinking is that our code in SVN should always be policy compliant, meaning that a release at any time should never be a problem. What will probably work a lot better is for compliance to be enforced at the source level, and here a compliance plugin hooked into the test phase can check for all the various things like license headers on files etc as required by the project. So rather than chase people around months after code was committed to bring it into compliance, the developer of a plugin can get immediate feedback while they are developing to say that files X, Y and Z are non compliant and need to be fixed. Extra points if the plugin can auto-fix some of the issues. that sounds very reasonable to have running in Continuum. Some time ago i added CPD check to the Maven parent pom but had to be commented out because not all projects comply Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLBeans Plugin Release
None of the issues assigned to 2.0.1 are critical for geronimo. for geronimo the most important is http://jira.codehaus.org/browse/ MXMLBEANS-19, but that requires xmlbeans to release a correct pom instead of the incorrect one that has no attribution or known origin and that the maven project refuses to fix and IMO should go with upgrading the maven plugin to use xmlbeans 2.2.0. See http:// issues.apache.org/jira/browse/XMLBEANS-277. http://jira.codehaus.org/browse/MXMLBEANS-22 would be cool but requires upgrading to xmlbeans 2.1.0 and that isn't in maven repos. I'd hate to see what you come up with for a pom for it based on the one for 2.0.0. I'd suggest delaying that until xmlbeans approves a set of poms for the 2.2.0 jars. http://jira.codehaus.org/browse/MXMLBEANS-2 appears to be partially fixed (?) but is not a problem for apache projects. thanks david jencks On Dec 13, 2006, at 5:26 PM, Jason van Zyl wrote: Hi, The Geronimo folks need a release of the XMLBeans plugins, could someone help me look at the issues and see if the issues for 2.0.1 can be pushed off to a 2.0.2 or if the can be cleared up quickly. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLBeans Plugin Release
from the IDE support perspective,it would be nice to have http://jira.codehaus.org/browse/MXMLBEANS-28 fixed. Milos On 12/14/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, The Geronimo folks need a release of the XMLBeans plugins, could someone help me look at the issues and see if the issues for 2.0.1 can be pushed off to a 2.0.2 or if the can be cleared up quickly. Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r487139 - /maven/sandbox/plugins/maven-swizzle-plugin/pom.xml
Hi Dennis, Thanks for the edits. Docck checks for the two reporting (javadoc and jxr) plugins though. Should docck exclude the two reporting plugins from the check/list of errors then? Regards, John On 12/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dennisl Date: Thu Dec 14 00:50:11 2006 New Revision: 487139 URL: http://svn.apache.org/viewvc?view=revrev=487139 Log: o Remove reporting plugins that are available in maven-plugin-surrogate-parent. You use mvn -Preporting ... to activate those plugins. Modified: maven/sandbox/plugins/maven-swizzle-plugin/pom.xml Modified: maven/sandbox/plugins/maven-swizzle-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/sandbox/plugins/maven-swizzle-plugin/pom.xml?view=diffrev=487139r1=487138r2=487139 == --- maven/sandbox/plugins/maven-swizzle-plugin/pom.xml (original) +++ maven/sandbox/plugins/maven-swizzle-plugin/pom.xml Thu Dec 14 00:50:11 2006 @@ -1,83 +1,71 @@ -!-- - -Copyright 2006 - -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -License); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - -http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License. --- - -project xmlns=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; - parent -artifactIdmaven-plugins/artifactId -groupIdorg.apache.maven.plugins/groupId -version4/version - /parent - modelVersion4.0.0/modelVersion - artifactIdmaven-swizzle-plugin/artifactId - packagingmaven-plugin/packaging - version1.0-SNAPSHOT/version - namemaven-swizzle-plugin Maven Mojo/name - urlhttp://maven.apache.org/url - build -plugins - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-site-plugin/artifactId -configuration - excludeModulesorg/codehaus/plexus/swizzle/*.vm/excludeModules -/configuration - /plugin -/plugins - /build - reporting -plugins - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-javadoc-plugin/artifactId - /plugin - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-jxr-plugin/artifactId - /plugin -/plugins - /reporting - dependencies -dependency - groupIdorg.apache.maven/groupId - artifactIdmaven-plugin-api/artifactId - version2.0/version -/dependency -dependency - groupIdjunit/groupId - artifactIdjunit/artifactId - version3.8.1/version - scopetest/scope -/dependency -dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-swizzle/artifactId - version1.0-SNAPSHOT/version -/dependency -dependency - groupIdorg.apache.maven.shared/groupId - artifactIdmaven-plugin-testing-harness/artifactId - version1.0-beta-1/version - scopetest/scope -/dependency - /dependencies -/project +!-- + +Copyright 2006 + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +License); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +-- + +project xmlns=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; + parent +artifactIdmaven-plugins/artifactId +groupIdorg.apache.maven.plugins/groupId +version4/version + /parent + modelVersion4.0.0/modelVersion + artifactIdmaven-swizzle-plugin/artifactId + packagingmaven-plugin/packaging + version1.0-SNAPSHOT/version + namemaven-swizzle-plugin Maven Mojo/name +
Re: svn commit: r487139 - /maven/sandbox/plugins/maven-swizzle-plugin/pom.xml
John Tolentino wrote: Hi Dennis, Thanks for the edits. Docck checks for the two reporting (javadoc and jxr) plugins though. Should docck exclude the two reporting plugins from the check/list of errors then? No I don't think so. These two plugins had to be moved to a profile because of the circular dependency issue. This is only necessary for our maven-plugins though. Any other project that uses docck does not have this problem. To avoid the errors from docck when working on maven-plugins (i.e org.apache.maven.plugins) you just need to add the profile, like this: mvn -Preporting docck:check Regards, John On 12/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dennisl Date: Thu Dec 14 00:50:11 2006 New Revision: 487139 URL: http://svn.apache.org/viewvc?view=revrev=487139 Log: o Remove reporting plugins that are available in maven-plugin-surrogate-parent. You use mvn -Preporting ... to activate those plugins. Modified: maven/sandbox/plugins/maven-swizzle-plugin/pom.xml Modified: maven/sandbox/plugins/maven-swizzle-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/sandbox/plugins/maven-swizzle-plugin/pom.xml?view=diffrev=487139r1=487138r2=487139 == --- maven/sandbox/plugins/maven-swizzle-plugin/pom.xml (original) +++ maven/sandbox/plugins/maven-swizzle-plugin/pom.xml Thu Dec 14 00:50:11 2006 @@ -1,83 +1,71 @@ -!-- - -Copyright 2006 - -Licensed to the Apache Software Foundation (ASF) under one -or more contributor license agreements. See the NOTICE file -distributed with this work for additional information -regarding copyright ownership. The ASF licenses this file -to you under the Apache License, Version 2.0 (the -License); you may not use this file except in compliance -with the License. You may obtain a copy of the License at - -http://www.apache.org/licenses/LICENSE-2.0 - -Unless required by applicable law or agreed to in writing, -software distributed under the License is distributed on an -AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -KIND, either express or implied. See the License for the -specific language governing permissions and limitations -under the License. --- - -project xmlns=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; - parent -artifactIdmaven-plugins/artifactId -groupIdorg.apache.maven.plugins/groupId -version4/version - /parent - modelVersion4.0.0/modelVersion - artifactIdmaven-swizzle-plugin/artifactId - packagingmaven-plugin/packaging - version1.0-SNAPSHOT/version - namemaven-swizzle-plugin Maven Mojo/name - urlhttp://maven.apache.org/url - build -plugins - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-site-plugin/artifactId -configuration - excludeModulesorg/codehaus/plexus/swizzle/*.vm/excludeModules -/configuration - /plugin -/plugins - /build - reporting -plugins - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-javadoc-plugin/artifactId - /plugin - plugin -groupIdorg.apache.maven.plugins/groupId -artifactIdmaven-jxr-plugin/artifactId - /plugin -/plugins - /reporting - dependencies -dependency - groupIdorg.apache.maven/groupId - artifactIdmaven-plugin-api/artifactId - version2.0/version -/dependency -dependency - groupIdjunit/groupId - artifactIdjunit/artifactId - version3.8.1/version - scopetest/scope -/dependency -dependency - groupIdorg.codehaus.plexus/groupId - artifactIdplexus-swizzle/artifactId - version1.0-SNAPSHOT/version -/dependency -dependency - groupIdorg.apache.maven.shared/groupId - artifactIdmaven-plugin-testing-harness/artifactId - version1.0-beta-1/version - scopetest/scope -/dependency - /dependencies -/project +!-- + +Copyright 2006 + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +License); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +-- + +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; +
Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.
Hi, If I understand correctly, the problem is that a 'staged' release still contains a SNAPSHOT keyword in the metadata/filename? Also, how would you see snapshot 'releases' without a snapshot keyword? If there's no indicator (timestamp?) in the filename, you'll overwrite the previous deployed versions, which is bad. Personally I'm pro release-candidate marking of artifacts. Either you have a '1.0-timestamp' release candidate version/file, or '1.0-rc1'. Doesn't really matter except that -rcX is more human readable. All snapshot deployments of artifacts could then be seen as release candidates/staged artifacts. What if maven understood the difference between the version in the pom and the version in the filename? You could deploy a release candidate with -rc1 (or timestamp) in the filename. This file will never change. The POM itself mentions the version without the -rc1. Then all you have to do when promoting a staged release to a real release is move the files to another directory (one without -SNAPSHOT or -rcX in the name), and rename the files in the process. No file contents have to be changed. You can never get access to that release candidate unless you specify '-rc1' in the version tag of dependencies on that artifact. Example of the repo structure to clarify things: groupId/ foo/ 1.0-rc1/ foo-1.0-rc1.jar foo-1.0-rc1.pom (version tag here says '1.0') 1.0/ ... bar/ 1.0-rc1/ bar-1.0-rc1.jar bar-1.0-rc1.pom (version tag here says '1.0') 1.0/ ... For projects apart from foo and bar that depend on this artifact, this works (comparable to SNAPSHOT artifacts). For dependencies of the rc artifact, it won't, unless you release per artifact: Assume both foo and bar are in the same release cycle, and foo depends on bar. The foo pom cannot be changed when released, so it's dependency on bar has to specify 1.0-rc1. This is a problem. But easily resolved: groupId/ foo/ 1.0/ maven-metadata.xml The metadata file mentiones that 1.0 is not released yet, and lists all release candidates. So when resolving bar-1.0 from foo, the metadata file is consulted and the 1.0-rc1 is used. The bad thing about this is that this works like SNAPSHOT resolution, except instead of specifying '1.0-SNAPSHOT' and getting '1.0-latest-timestamp' you specify '1.0' and get the latest '1.0-rcX'. This is not necessarily a bad thing: if you want to promote foo, you also have to release bar. Maven should check if 1.0 is resolved to 1.0 or an rc before releasing. Also something could be done in maven internally to mark projects as non-final, since it knows when resolving 1.0 that it got an RC. The scheme above is almost identical to SNAPSHOT resolution. Differences: - no SNAPSHOT tag in the artifact files themselves - wheter something is a SNAPSHOT is determined from the absense of the artifact in the correct version dir (1.0 is a snapshot since 1.0/ doesn't contain foo-1.0.pom and the metadata file points to another version). If you look at a pom file that has no SNAPSHOT in there, you won't know for sure if it's a snapshot unless you check where it's resolved from. Normally this is never a problem - all artifacts are resolved from the local repo. When creating wars or other compound artifacts, or assemblies, the filenames should match the version tag. For instance, assume foo is an ear project, embedding bar. If bar would be embedded as bar-1.0-rc1.jar, foo's contents would have to be changed on the final release because bar's filename would change, even though the version wouldn't. So when looking at a file bar-1.0.jar and the embedding pom you can only tell that it's a snapshot using the metadata file from groupId/bar/1.0/. Thoughts? Dan Fabulich wrote: Thanks for a great e-mail Joakim. I wanted to chime in with my two cents... (I've been off the radar for a couple of months while waiting for permission to sign my ICLA; it's in now, and I'm now back to paying more careful attention to this process... forgive me if some of this has already been covered.) One of the goals I know we've expressed before (but not explicitly listed here) is that Maven's release process should lead by example: other projects (whether open-source or closed-source) who haven't put as much thought into release engineering as we have should look to us as an example of the right way to do it. IMO, the requirements around SNAPSHOT releases is an important difference between open-source requirements for the release process and closed-source requirements... In this e-mail I want to describe an alternative release process (overlapping with the one Joakim described) that never uses SNAPSHOT and which is more appropriate to some organizations, perhaps especially closed-source ones. I think we all agree that it's bad (at least a little bit) to change things at the last minute before release (whether it be source code, binaries, or even your build process); one goal of
Being able to modify HTTP headers for a request
Joakime, Do you think you could add something that would allow us to add to set of headers that are sent to a client, and set the client string? In Maven I would like to accurately keep track of what versions of Maven are actively in use and I think being able to send version information along with the request and/or version numbers in the client string would help us tremendously in knowing who is actually using what. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-ear-plugin and dependencies
Hi all, Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get the application.xml file built correctly. Between maven1 and maven2, the ejb plugin lost it's ability to bundle dependencies inside the ejb. This means (as I understand it) that it's now up to the ear plugin to add all the dependencies to the application.xml file. However, it seems that the maven-ear-plugin does not have any documented functionality to add dependencies to application.xml, except for explicitly declaring dependencies using the jarModule tag. This duplicates the dependency list, and removes all the power behind transitive dependency management, which is supposed to handle dependencies for you. Is there a setting I am not seeing, or does the ear plugin have no dependency management features at all? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote: I don't see that there is a consistent view yet on this. It would be nice to get to a conclusion on whether the Maven community would like to work with the downstream distros teams so that we can provide a consistent and good experience. Is there any more information that is needed to get to a view point, and if so how can I help? If the distros works with us to provide something that is familiar to our current users, to which our documentation, practices, and current body of user knowledge apply then I don't think anyone would be opposed here. So that means: - Using an installation layout that is consistent with our current setup This seems reasonable - we do need to work with jpackage so there might be some items that come from that. If there are maybe we can see if we can do it in a consistent way that can work for mainline also. - Using the Maven repository as the source for satisfying dependencies for development work That was my assumption and if we can get all the items we needed merged in a way maven is happy with upstream there would be no reason to do anything else - Maven running with a standard JDK and not being compiled with GJC or anything weird like that. With Java being GPL now that shouldn't be a problem There is a timeline issue with this. If we complete the Maven work before JDK (GPL) is available then we might need to prove we can build with GCJ, or build with mainline of the GPL version which will be ahead 1.6. Don't really know if worth debating now as GPL JDK is also a moving target and we should eval once we get closer to completing the other items that need to be done. A couple questions that weren't really answered were: - How far into the graph do you need to build from sources - All the way, or we can limit some modules and add them incrementally, or maybe if the user needs them the we can download them when mvn is run much like anaconda. - Would a self-contained Maven repository with the binary dependencies work and then build Maven itself from source or do you want to walk back down the entire graph? - All dependencies that are shipped in the distro or used to build the distro need to be able to be built from source. Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
On 14 Dec 06, at 9:46 AM 14 Dec 06, Carl Trieloff wrote: Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? If they are Apache committers then they already have access to our sandbox. If they aren't then we can do it somewhere like the mojo project where we can give you access. Jason. Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat failure
Has anyone had a chance to look at this, to see if there's something
obviously wrong? If it looks ok, I'll start looking anywhere else
you might suggest. I'm really at a loss at this point.
On Dec 12, 2006, at 4:06 PM, Stephen Pietrowicz wrote:
That didn't work. Here is my addition to server.xml:
Resource name=jdbc/continuum auth=Container
type=javax.sql.DataSource
ResourceParams name=jdbc/continuum
parameter
namemaxWait/name
value5000/value
/parameter
parameter
namemaxActive/name
value4/value
/parameter
parameter
namepassword/name
value/value
/parameter
parameter
nameurl/name
valuejdbc:derby:target/database/continuum/value
/parameter
parameter
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/parameter
parameter
namemaxIdle/name
value2/value
/parameter
parameter
nameusername/name
valuecontinuum/value
/parameter
/ResourceParams
/Resource
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
ResourceParams name=jdbc/users
parameter
namemaxWait/name
value5000/value
/parameter
parameter
namemaxActive/name
value4/value
/parameter
parameter
namepassword/name
value/value
/parameter
parameter
nameurl/name
valuejdbc:derby:target/database/users/value
/parameter
parameter
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/parameter
parameter
namemaxIdle/name
value2/value
/parameter
parameter
nameusername/name
valuecontinuum-users/value
/parameter
/ResourceParams
/Resource
and here's my continuum.xml:
?xml version='1.0' encoding='utf-8'?
Context displayName=Continuum Webapp docBase=/home/srp/tomcat/
apache-tomcat-5.5.20/webapps/continuum-webapp-1.1-SNAPSHOT.war
workDir=/home/srp/temp_work
ResourceLink name=jdbc/continuum type=
org.apache.derby.jdbc.EmbeddedDriver global=jdbc/continuum/
ResourceLink name=jdbc/users type=
org.apache.derby.jdbc.EmbeddedDriver global=jdbc/users/
/Context
On Dec 12, 2006, at 3:25 PM, Rahul Thakur wrote:
As a workaround - can you try moving the Resource .../ config
from continuum.xml to server.xml under global resoures (just like
mentioned on that thread). Pretty sure I have seen similar errors
with JNDI resource look ups in tomcat, but can't remember the
solution off hand.
Cheers,
Rahul
Stephen Pietrowicz wrote:
I hadn't seen that thread. Thanks for the pointer to it.
I do get same message that the originator of that thread gets:
---
2006-12-12 14:20:31,590 [http-8080-Processor23] INFO
PlexusContainer- Loading on start [role]:
[org.apache.maven.continuum.Continuum]
2006-12-12 14:20:34,287 [http-8080-Processor23] ERROR 1-
SNAPSHOT]- Exception sending context
initialized event to listener instance of class
org.codehaus.plexus.xwork.PlexusLifecycleListener
org.jpox.exceptions.ConnectionFactoryNotFoundException:
Connection Factory java:comp/env/jdbc/continuum not found
at
org.jpox.AbstractPersistenceManagerFactory.lookupDataSource
(AbstractPersistenceManagerFactory.java:175)
[ rest of stack trace deleted]
but still haven't figured out the solution, even after adding
the continuum.xml file to the tomcat conf directory.
I'm not a Tomcat expert, so I think there are several other
things I need to do, but I can't tell what.
Here's what I did:
This morning I downloaded the bin of Tomcat-5.5.20, along with
the admin tools, and extracted everything. I added an account
with manager and admin to the tomcat-users.xml, and then I
started Tomcat with bin/startup.sh
For continuum, I did this:
mvn clean install
Back in Tomcat I went to the manager, and went down to the Deploy
section of the page and uploaded the war file from the
continuum-webapp directory to Tomcat.
Under applications on that page, it now shows /continuum-
webapp-1.1-SNAPSHOT.
I click the start link on that line, and it gives me the message:
FAIL - Application at context path /continuum-webapp-1.1-
SNAPSHOT could not be started.
and got the same error message in catalina.out as listed above.
The continuum.xml file I have is:
?xml version=1.0 encoding=UTF-8?
Context path=/continuum-webapp-1.1-SNAPSHOT
docBase=${catalina.base}/webapps/continuum-webapp-1.1-
SNAPSHOT
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
username=sa
password=
driverClassName=org.apache.derby.jdbc.EmbeddedDriver
url=jdbc:derby:target/database/users;create=true
/
Resource name=jdbc/continuum auth=Container
type=javax.sql.DataSource
Re: Maven and Fedora
Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Note that this doesn't require building everything from source all in one go. That's impossible since there are cyclic dependencies, e.g. gcc is used to build itself. It *does* require that we can completely turn off all maven's attempts at remote access and preferably turn them into nice error messages. Now I'm not sure how this translates into the building one level from source vs building all levels from source terminology, I would phrase it as we need to build all levels from source, but we can build them one level at a time. This strict offline bootstrapping requirement is necessary for producing consistent OS builds. This does make it clear that a self contained binary repository will work, as long as the self contained binary repository is part of every fedora install. The only issue there is one of JPP vs maven conventions for jar locations. --Rafael Carl Trieloff wrote: Jason van Zyl wrote: On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote: I don't see that there is a consistent view yet on this. It would be nice to get to a conclusion on whether the Maven community would like to work with the downstream distros teams so that we can provide a consistent and good experience. Is there any more information that is needed to get to a view point, and if so how can I help? If the distros works with us to provide something that is familiar to our current users, to which our documentation, practices, and current body of user knowledge apply then I don't think anyone would be opposed here. So that means: - Using an installation layout that is consistent with our current setup This seems reasonable - we do need to work with jpackage so there might be some items that come from that. If there are maybe we can see if we can do it in a consistent way that can work for mainline also. - Using the Maven repository as the source for satisfying dependencies for development work That was my assumption and if we can get all the items we needed merged in a way maven is happy with upstream there would be no reason to do anything else - Maven running with a standard JDK and not being compiled with GJC or anything weird like that. With Java being GPL now that shouldn't be a problem There is a timeline issue with this. If we complete the Maven work before JDK (GPL) is available then we might need to prove we can build with GCJ, or build with mainline of the GPL version which will be ahead 1.6. Don't really know if worth debating now as GPL JDK is also a moving target and we should eval once we get closer to completing the other items that need to be done. A couple questions that weren't really answered were: - How far into the graph do you need to build from sources - All the way, or we can limit some modules and add them incrementally, or maybe if the user needs them the we can download them when mvn is run much like anaconda. - Would a self-contained Maven repository with the binary dependencies work and then build Maven itself from source or do you want to walk back down the entire graph? - All dependencies that are shipped in the distro or used to build the distro need to be able to be built from source. Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat failure
Look at this file :
http://svn.apache.org/repos/asf/maven/continuum/trunk/continuum-webapp-test/src/test/tomcat5x/conf/Catalina/localhost/continuum.xml
We use it for our web-ui test and it works fine.
Emmanuel
Stephen Pietrowicz a écrit :
Has anyone had a chance to look at this, to see if there's something
obviously wrong? If it looks ok, I'll start looking anywhere else you
might suggest. I'm really at a loss at this point.
On Dec 12, 2006, at 4:06 PM, Stephen Pietrowicz wrote:
That didn't work. Here is my addition to server.xml:
Resource name=jdbc/continuum auth=Container
type=javax.sql.DataSource
ResourceParams name=jdbc/continuum
parameter
namemaxWait/name
value5000/value
/parameter
parameter
namemaxActive/name
value4/value
/parameter
parameter
namepassword/name
value/value
/parameter
parameter
nameurl/name
valuejdbc:derby:target/database/continuum/value
/parameter
parameter
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/parameter
parameter
namemaxIdle/name
value2/value
/parameter
parameter
nameusername/name
valuecontinuum/value
/parameter
/ResourceParams
/Resource
Resource name=jdbc/users auth=Container type=javax.sql.DataSource
ResourceParams name=jdbc/users
parameter
namemaxWait/name
value5000/value
/parameter
parameter
namemaxActive/name
value4/value
/parameter
parameter
namepassword/name
value/value
/parameter
parameter
nameurl/name
valuejdbc:derby:target/database/users/value
/parameter
parameter
namedriverClassName/name
valueorg.apache.derby.jdbc.EmbeddedDriver/value
/parameter
parameter
namemaxIdle/name
value2/value
/parameter
parameter
nameusername/name
valuecontinuum-users/value
/parameter
/ResourceParams
/Resource
and here's my continuum.xml:
?xml version='1.0' encoding='utf-8'?
Context displayName=Continuum Webapp
docBase=/home/srp/tomcat/apache-tomcat-5.5.20/webapps/continuum-webapp-1.1-SNAPSHOT.war
workDir=/home/srp/temp_work
ResourceLink name=jdbc/continuum type=
org.apache.derby.jdbc.EmbeddedDriver global=jdbc/continuum/
ResourceLink name=jdbc/users type=
org.apache.derby.jdbc.EmbeddedDriver global=jdbc/users/
/Context
On Dec 12, 2006, at 3:25 PM, Rahul Thakur wrote:
As a workaround - can you try moving the Resource .../ config from
continuum.xml to server.xml under global resoures (just like
mentioned on that thread). Pretty sure I have seen similar errors
with JNDI resource look ups in tomcat, but can't remember the
solution off hand.
Cheers,
Rahul
Stephen Pietrowicz wrote:
I hadn't seen that thread. Thanks for the pointer to it.
I do get same message that the originator of that thread gets:
---
2006-12-12 14:20:31,590 [http-8080-Processor23] INFO
PlexusContainer- Loading on start [role]:
[org.apache.maven.continuum.Continuum]
2006-12-12 14:20:34,287 [http-8080-Processor23] ERROR
1-SNAPSHOT]- Exception sending context
initialized event to listener instance of class
org.codehaus.plexus.xwork.PlexusLifecycleListener
org.jpox.exceptions.ConnectionFactoryNotFoundException: Connection
Factory java:comp/env/jdbc/continuum not found
at
org.jpox.AbstractPersistenceManagerFactory.lookupDataSource(AbstractPersistenceManagerFactory.java:175)
[ rest of stack trace deleted]
but still haven't figured out the solution, even after adding the
continuum.xml file to the tomcat conf directory.
I'm not a Tomcat expert, so I think there are several other things I
need to do, but I can't tell what.
Here's what I did:
This morning I downloaded the bin of Tomcat-5.5.20, along with the
admin tools, and extracted everything. I added an account with
manager and admin to the tomcat-users.xml, and then I started
Tomcat with bin/startup.sh
For continuum, I did this:
mvn clean install
Back in Tomcat I went to the manager, and went down to the Deploy
section of the page and uploaded the war file from the
continuum-webapp directory to Tomcat.
Under applications on that page, it now shows
/continuum-webapp-1.1-SNAPSHOT.
I click the start link on that line, and it gives me the message:
FAIL - Application at context path /continuum-webapp-1.1-SNAPSHOT
could not be started.
and got the same error message in catalina.out as listed above.
The continuum.xml file I have is:
?xml version=1.0 encoding=UTF-8?
Context path=/continuum-webapp-1.1-SNAPSHOT
docBase=${catalina.base}/webapps/continuum-webapp-1.1-SNAPSHOT
Resource name=jdbc/users auth=Container
type=javax.sql.DataSource
username=sa
password=
Re: Maven and Fedora
On 14 Dec 06, at 10:30 AM 14 Dec 06, Rafael Schloming wrote: Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Sure, but for Maven usage a JDK + a tarball of Maven in all practical instances is enough for someone to get work done. Note that this doesn't require building everything from source all in one go. That's impossible since there are cyclic dependencies, e.g. gcc is used to build itself. It *does* require that we can completely turn off all maven's attempts at remote access and preferably turn them into nice error messages. Now I'm not sure how this translates into the building one level from source vs building all levels from source terminology, I would phrase it as we need to build all levels from source, but we can build them one level at a time. This strict offline bootstrapping requirement is necessary for producing consistent OS builds. This does make it clear that a self contained binary repository will work, as long as the self contained binary repository is part of every fedora install. The only issue there is one of JPP vs maven conventions for jar locations. --Rafael Carl Trieloff wrote: Jason van Zyl wrote: On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote: I don't see that there is a consistent view yet on this. It would be nice to get to a conclusion on whether the Maven community would like to work with the downstream distros teams so that we can provide a consistent and good experience. Is there any more information that is needed to get to a view point, and if so how can I help? If the distros works with us to provide something that is familiar to our current users, to which our documentation, practices, and current body of user knowledge apply then I don't think anyone would be opposed here. So that means: - Using an installation layout that is consistent with our current setup This seems reasonable - we do need to work with jpackage so there might be some items that come from that. If there are maybe we can see if we can do it in a consistent way that can work for mainline also. - Using the Maven repository as the source for satisfying dependencies for development work That was my assumption and if we can get all the items we needed merged in a way maven is happy with upstream there would be no reason to do anything else - Maven running with a standard JDK and not being compiled with GJC or anything weird like that. With Java being GPL now that shouldn't be a problem There is a timeline issue with this. If we complete the Maven work before JDK (GPL) is available then we might need to prove we can build with GCJ, or build with mainline of the GPL version which will be ahead 1.6. Don't really know if worth debating now as GPL JDK is also a moving target and we should eval once we get closer to completing the other items that need to be done. A couple questions that weren't really answered were: - How far into the graph do you need to build from sources - All the way, or we can limit some modules and add them incrementally, or maybe if the user needs them the we can download them when mvn is run much like anaconda. - Would a self-contained Maven repository with the binary dependencies work and then build Maven itself from source or do you want to walk back down the entire graph? - All dependencies that are shipped in the distro or used to build the distro need to be able to be built from source. Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Future of the Release Process.
On Wednesday 13 December 2006 18:54, Tom Huybrechts wrote: 6) All source files in the sources.jar files will contain the following header. ---(snip)--- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ---(snip)--- Ditto for the pom itself ? Tom Yes, it should. However, there is a bug in Maven 2.0.4 that wipes out the headers on the deployed poms. Jason has a fix for that which will hopefully make it into 2.0.5. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Being able to modify HTTP headers for a request
I would like to have this optionally work across all current (and future) wagon wheels (providers). How about the following methods? for reference - http://maven.apache.org/wagon/wagon-provider-api/apidocs/org/apache/maven/wagon/Wagon.html Wagon.setClientProperties( Properties ); Wagon.setClientProperty( String key, String value ); That way, you can provide the data, pass it anonymously to the active wagon, and (if the wagon supports it), add those key/value pairs to any sort of client identification process in the wagon? http, http-lightweight, and webdav would obviously include http request headers. ftp, file, and ssh providers would essentially ignore the ClientProperties provided. Should we prevent, or allow, the ability to set any of the standard client properties? Such as 'USER_AGENT', or 'REFERER'? I'm leaning towards allowing it, but tossing a warning when it an overwrite situation occurs. Sound good? - Joakim Jason van Zyl wrote: Joakime, Do you think you could add something that would allow us to add to set of headers that are sent to a client, and set the client string? In Maven I would like to accurately keep track of what versions of Maven are actively in use and I think being able to send version information along with the request and/or version numbers in the client string would help us tremendously in knowing who is actually using what. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Being able to modify HTTP headers for a request
On 14 Dec 06, at 12:24 PM 14 Dec 06, Joakim Erdfelt wrote: I would like to have this optionally work across all current (and future) wagon wheels (providers). How about the following methods? for reference - http://maven.apache.org/wagon/wagon-provider-api/apidocs/org/apache/ maven/wagon/Wagon.html Wagon.setClientProperties( Properties ); Wagon.setClientProperty( String key, String value ); That way, you can provide the data, pass it anonymously to the active wagon, and (if the wagon supports it), add those key/value pairs to any sort of client identification process in the wagon? Good idea. http, http-lightweight, and webdav would obviously include http request headers. ftp, file, and ssh providers would essentially ignore the ClientProperties provided. Should we prevent, or allow, the ability to set any of the standard client properties? Such as 'USER_AGENT', or 'REFERER'? The USER_AGENT is something I would like to be able to set. For example in Maven I want to set it. I'm leaning towards allowing it, but tossing a warning when it an overwrite situation occurs. Yah, it's up to people using the code. Let them do what they want. What's the harm? Sound good? +1 - Joakim Jason van Zyl wrote: Joakime, Do you think you could add something that would allow us to add to set of headers that are sent to a client, and set the client string? In Maven I would like to accurately keep track of what versions of Maven are actively in use and I think being able to send version information along with the request and/or version numbers in the client string would help us tremendously in knowing who is actually using what. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
Hi, This has been tackled a dozen of times and I am not sure it has anything to do with the EAR plugin, at least if we follow the spec. If I am wrong, please let me know. The valid way to bundle shared components/libs in a EAR is to define the Class-Path entry of the manifest in EJB module(s) using the component. It's certainly not by adding them in a java module entry in the application.xml even though some application servers support this (JBoss namely). The EAR plugin supports the APP-INF/lib weblogic's trick by using the defaultJarBundleDir setting though. So I wouldn't say the EAR plugin has no dependency management features at all, I don't even see the point actually :) Make sure that your classpath entries got generated on the EJB side and it will just run fine. Now I agree it's not always easy so if you have ideas to improve, let us know. I am not sure we can do something at the EAR level, except generating EARs that do not follow the spec. Cheers, Stéphane On 12/14/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get the application.xml file built correctly. Between maven1 and maven2, the ejb plugin lost it's ability to bundle dependencies inside the ejb. This means (as I understand it) that it's now up to the ear plugin to add all the dependencies to the application.xml file. However, it seems that the maven-ear-plugin does not have any documented functionality to add dependencies to application.xml, except for explicitly declaring dependencies using the jarModule tag. This duplicates the dependency list, and removes all the power behind transitive dependency management, which is supposed to handle dependencies for you. Is there a setting I am not seeing, or does the ear plugin have no dependency management features at all? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
On Dec 14, 2006, at 11:05 AM, Stephane Nicoll wrote: Hi, This has been tackled a dozen of times and I am not sure it has anything to do with the EAR plugin, at least if we follow the spec. If I am wrong, please let me know. The valid way to bundle shared components/libs in a EAR is to define the Class-Path entry of the manifest in EJB module(s) using the component. It's certainly not by adding them in a java module entry in the application.xml even though some application servers support this (JBoss namely). The EAR plugin supports the APP-INF/lib weblogic's trick by using the defaultJarBundleDir setting though. So I wouldn't say the EAR plugin has no dependency management features at all, I don't even see the point actually :) Make sure that your classpath entries got generated on the EJB side and it will just run fine. Now I agree it's not always easy so if you have ideas to improve, let us know. I am not sure we can do something at the EAR level, except generating EARs that do not follow the spec. I agree that spec support is the way to go. the jee5 ear lets you specify a lib directory (default is lib) where all the jars inside get added to the classpath. We could work on jee5 support, that ought to keep everyone happy. Does the defaultJarBundleDir do this? I guess if so it might need to be put in the generated application.xml?? As you can tell I haven't looked at what the plugin actually does now. thanks david jencks Cheers, Stéphane On 12/14/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get the application.xml file built correctly. Between maven1 and maven2, the ejb plugin lost it's ability to bundle dependencies inside the ejb. This means (as I understand it) that it's now up to the ear plugin to add all the dependencies to the application.xml file. However, it seems that the maven-ear-plugin does not have any documented functionality to add dependencies to application.xml, except for explicitly declaring dependencies using the jarModule tag. This duplicates the dependency list, and removes all the power behind transitive dependency management, which is supposed to handle dependencies for you. Is there a setting I am not seeing, or does the ear plugin have no dependency management features at all? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
On 12/14/06, David Jencks [EMAIL PROTECTED] wrote: I agree that spec support is the way to go. the jee5 ear lets you specify a lib directory (default is lib) where all the jars inside get added to the classpath. We could work on jee5 support, that ought to keep everyone happy. Does the defaultJarBundleDir do this? I guess if so it might need to be put in the generated application.xml?? As you can tell I haven't looked at what the plugin actually does now. Well yes it does just do [...] configuration defaultJarBundleDirlib/defaultJarBundleDir [...] /configuration No we can imagine configuration profiles. If we're using Jave EE5, this is the default value and libraries (artifact with type = jar) are automatically copied to this lib directory. Sounds good to me. There is no solution for 1.3 and 1.4 though but it's a start. Thanks, Stéphane thanks david jencks Cheers, Stéphane On 12/14/06, Graham Leggett [EMAIL PROTECTED] wrote: Hi all, Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get the application.xml file built correctly. Between maven1 and maven2, the ejb plugin lost it's ability to bundle dependencies inside the ejb. This means (as I understand it) that it's now up to the ear plugin to add all the dependencies to the application.xml file. However, it seems that the maven-ear-plugin does not have any documented functionality to add dependencies to application.xml, except for explicitly declaring dependencies using the jarModule tag. This duplicates the dependency list, and removes all the power behind transitive dependency management, which is supposed to handle dependencies for you. Is there a setting I am not seeing, or does the ear plugin have no dependency management features at all? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven-timestamp-plugin
In a #maven discussion, it was uncovered that a timestamp plugin was written for the geronimo project. https://issues.apache.org/jira/browse/GERONIMO-1659 Is there any interest in bringing this into maven-plugins for others to use? +1
Re: Maven-timestamp-plugin
On 14 Dec 06, at 3:22 PM 14 Dec 06, Brian E. Fox wrote:
In a #maven discussion, it was uncovered that a timestamp plugin was
written for the geronimo project.
https://issues.apache.org/jira/browse/GERONIMO-1659
Is there any interest in bringing this into maven-plugins for
others to
use?
Is it simply to put the timestamp in various resources?. For 2.0.4
users this would be good, but I think we can also work toward
providing a standard set of properties that can be used in mojos or
documentation. So that something like the timestamp would be
available with an expression like ${timestamp} in a mojo or an Apt/
Xdoc document.
Jason.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven-timestamp-plugin
I think the specific use case is to make it get into filtered resources.
It would be better if it was just available without a plugin but in
2.0.x there isn't any other way apparently.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 3:42 PM
To: Maven Developers List
Subject: Re: Maven-timestamp-plugin
On 14 Dec 06, at 3:22 PM 14 Dec 06, Brian E. Fox wrote:
In a #maven discussion, it was uncovered that a timestamp plugin was
written for the geronimo project.
https://issues.apache.org/jira/browse/GERONIMO-1659
Is there any interest in bringing this into maven-plugins for others
to use?
Is it simply to put the timestamp in various resources?. For 2.0.4 users
this would be good, but I think we can also work toward providing a
standard set of properties that can be used in mojos or documentation.
So that something like the timestamp would be available with an
expression like ${timestamp} in a mojo or an Apt/ Xdoc document.
Jason.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven-timestamp-plugin
I'm not sure this does anything useful. I recommend using antrun if you need timestamping. --jason -Original Message- From: Brian E. Fox [EMAIL PROTECTED] Date: Thu, 14 Dec 2006 15:22:08 To:Maven Developers List dev@maven.apache.org Subject: Maven-timestamp-plugin In a #maven discussion, it was uncovered that a timestamp plugin was written for the geronimo project. https://issues.apache.org/jira/browse/GERONIMO-1659 Is there any interest in bringing this into maven-plugins for others to use? +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven-timestamp-plugin
On 14 Dec 06, at 3:51 PM 14 Dec 06, Brian E. Fox wrote:
I think the specific use case is to make it get into filtered
resources.
It would be better if it was just available without a plugin but in
2.0.x there isn't any other way apparently.
It would be easy enough to put that in the resources plugin and
release it.
Jason.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 3:42 PM
To: Maven Developers List
Subject: Re: Maven-timestamp-plugin
On 14 Dec 06, at 3:22 PM 14 Dec 06, Brian E. Fox wrote:
In a #maven discussion, it was uncovered that a timestamp plugin was
written for the geronimo project.
https://issues.apache.org/jira/browse/GERONIMO-1659
Is there any interest in bringing this into maven-plugins for others
to use?
Is it simply to put the timestamp in various resources?. For 2.0.4
users
this would be good, but I think we can also work toward providing a
standard set of properties that can be used in mojos or documentation.
So that something like the timestamp would be available with an
expression like ${timestamp} in a mojo or an Apt/ Xdoc document.
Jason.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven-timestamp-plugin
FYI here you can find a similar plugin which can be used to set
various properties for resource filtering (timestamp/date, a
decorated version number...). This is actually only used for
Magnolia builds but maybe it could be useful to someone else:
http://svn.magnolia.info/svn/maven-plugins/
(repo at
http://svn.magnolia.info/maven/m2/info/magnolia/maven-setproperty-plugin/
)
fabrizio
On 12/14/06, Jason van Zyl [EMAIL PROTECTED] wrote:
On 14 Dec 06, at 3:51 PM 14 Dec 06, Brian E. Fox wrote:
I think the specific use case is to make it get into filtered
resources.
It would be better if it was just available without a plugin but in
2.0.x there isn't any other way apparently.
It would be easy enough to put that in the resources plugin and
release it.
Jason.
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 3:42 PM
To: Maven Developers List
Subject: Re: Maven-timestamp-plugin
On 14 Dec 06, at 3:22 PM 14 Dec 06, Brian E. Fox wrote:
In a #maven discussion, it was uncovered that a timestamp plugin was
written for the geronimo project.
https://issues.apache.org/jira/browse/GERONIMO-1659
Is there any interest in bringing this into maven-plugins for others
to use?
Is it simply to put the timestamp in various resources?. For 2.0.4
users
this would be good, but I think we can also work toward providing a
standard set of properties that can be used in mojos or documentation.
So that something like the timestamp would be available with an
expression like ${timestamp} in a mojo or an Apt/ Xdoc document.
Jason.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: On 14 Dec 06, at 10:30 AM 14 Dec 06, Rafael Schloming wrote: Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Sure, but for Maven usage a JDK + a tarball of Maven in all practical instances is enough for someone to get work done. I'm not sure what this has to do with my post. I'm just trying to explain fedora's bootstrapping requirements. Besides, even if a JDK + a tarball is enough to run maven itself, this doesn't really solve the problem maven users face when trying to distribute their software on fedora or any other OS for that matter. IMHO the key problem to solve is how to make maven builds produce software that is integrated with the target OS. Once we've done this then integrating maven with the target OS should be trivial since maven can build itself. This issue is really broader than just maven. It seems the defacto java packaging standard is to simply distribute a huge archive that includes every dependency, quite reminiscent of windows DLL hell. This may well be the only option available for windows, but for OSes like fedora where things like automatic dependency management, upgrades, and security fixes are the norm, this practice just doesn't scale. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
On 14 Dec 06, at 4:07 PM 14 Dec 06, Rafael Schloming wrote: Jason van Zyl wrote: On 14 Dec 06, at 10:30 AM 14 Dec 06, Rafael Schloming wrote: Just to clarify the building from source situation, the real requirement is that if we were in a concrete bunker somewhere with no connection to the outside world, and all we had was an installed fedora box + all the source rpms for fedora, we should be able to rebuild the entire OS. Sure, but for Maven usage a JDK + a tarball of Maven in all practical instances is enough for someone to get work done. I'm not sure what this has to do with my post. I'm just trying to explain fedora's bootstrapping requirements. Only a passing comment on the relevance of worrying about having to assume you were in a concrete bunker cut off from the rest of the world is all. Besides, even if a JDK + a tarball is enough to run maven itself, this doesn't really solve the problem maven users face when trying to distribute their software on fedora or any other OS for that matter. IMHO the key problem to solve is how to make maven builds produce software that is integrated with the target OS. Once we've done this then integrating maven with the target OS should be trivial since maven can build itself. This issue is really broader than just maven. It seems the defacto java packaging standard is to simply distribute a huge archive that includes every dependency, quite reminiscent of windows DLL hell. Hardly the case, and I think you are mistaken. For notorious messes like JBoss that have ridiculous and naive classloading mechanisms you can get rooked, but OSGi is proof that this doesn't have to be the case. Using RPMs will not help at all in cases where classloader hierarchies and classloaders do stupid things. In Java we don't care if you have three archives each with a different app that contains their own dependencies. We can run them in different VMs, and that's our virtualization. I think rpath is evidence that there's something wrong when you need to create a new OS image for pure isolation. Anyway doesn't matter if you want to try some stuff I think we've agreed we'll have a go at it. But I'm not even remotely sold on Java being packaged up as RPMs as being a good thing. This may well be the only option available for windows, but for OSes like fedora where things like automatic dependency management, upgrades, and security fixes are the norm, this practice just doesn't scale. Yah, I don't buy it. I don't know anyone who uses RPMs to do anything with Java. Jason. --Rafael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Site Plugin
Hi, I have managed to get the site plugin working with 2.0.4 and it really wasn't a simple matter of rolling back some stuff. In order for the site plugin to work with 2.0.4 the version of doxia that is in MAVEN_HOME/lib must be used which is doxia-1.0-alpha-7. The version of doxia in trunk is not very much like 1.0-alpha-7 at all and creating a bridge required a compat package with bits from maven- reporting, doxia-core, doxia-site-renderer, doxia-document-render. Maybe I'm missing something but I don't see how what's in trunk could work at all as there are so many class that are different with methods removed, or classes not present in doxia-1.0-alpha-7. Another problem was relying on some changes in plexus-utils that are not available in the version used in 2.0.4 I have created a tag in svn that marks the point right before I created the bridge for reverting if something is wrong here: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-site-plugin- pre-compat-with-doxia-1.0-alpha-7/ I have created some notes about the compatibility here: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/ compatibility-notes.txt I have checked in what I have that makes it work for the /maven/ components site generation and I have deployed a snapshot that people can try: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/ plugins/maven-site-plugin/2.0-SNAPSHOT/ So for that poor fellow who was trying to jump through rings of fire to generate his sites, this one's for you :-) Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update: Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
We could add this to release plugin configuration in the parent POM.
On 14/12/2006, at 2:08 PM, Brian E. Fox wrote:
It looks like the -Preporting flag wasn't used when deploying the
sites.
Some of the reports might not be missed, but apparently this also
precludes the goal pages (ex:
http://maven.apache.org/plugins/maven-remote-resources-plugin/
bundle-moj
o.html). I redeployed all the sites listed below so they should be
updated after the resync (or whatever causes the delay).
New projects are obvious because the pages are missing. More
concerning
would be missing updates to existing projects because of this flag. Is
there a way to do this without relying on someone to remember to
add the
flag yet not cause the circular dependencies?
-Original Message-
From: Joakim Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 12:55 PM
To: Maven Developers List
Subject: Update: Re: [vote] maven release process ( gpg / javadoc /
site
/ source / remote-resources ) plugins.
Current releases performed...
maven-javadoc-plugin - 2.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-javadoc-plugin/2.2/
maven-source-plugin - 2.0.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-source-plugin/2.0.2/
maven-gpg-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-gpg-plugin/1.0-alpha-1/
maven-remote-resources-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-remote-resources-plugin/1.0-alpha-1/
(dependency) maven-downloader - 1.1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/shared/maven-downloader/1.1/
maven-site-plugin has not been released (yet) as the maven 2.1
dependency has not yet been removed.
jason said that kenney would remove it.
- Joakim
Joakim Erdfelt wrote:
After a chat with Jason about the new release process / staging /
etc...
I feel it is time to get a release out for the following plugins.
maven-gpg-plugin 1.0
maven-javadoc-plugin 2.2
maven-site-plugin 2.0
maven-source-plugin 2.0.2
maven-remote-resources-plugin 1.0
This will allow for the following ...
* release staging.
* gpg signing of all artifacts.
* ${artifactId}-${version}-sources.jar creation
* ${artifactId}-${version}-javadoc.jar creation
* Proper inclusion of the Apache LICENSE and NOTICE files.
I would like to call a vote on getting the 5 crucial plugins released
in a non-SNAPSHOT form.
Once these plugins are in place, the top level parent poms
(maven-parent and apache) can be updated to make these processes
standard for all releases.
To kick things off ...
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
- Joakim Erdfelt
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Update: Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
Does the release plugin deploy the site now?
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 5:58 PM
To: Maven Developers List
Subject: Re: Update: Re: [vote] maven release process ( gpg / javadoc /
site / source / remote-resources ) plugins.
We could add this to release plugin configuration in the parent POM.
On 14/12/2006, at 2:08 PM, Brian E. Fox wrote:
It looks like the -Preporting flag wasn't used when deploying the
sites.
Some of the reports might not be missed, but apparently this also
precludes the goal pages (ex:
http://maven.apache.org/plugins/maven-remote-resources-plugin/
bundle-moj
o.html). I redeployed all the sites listed below so they should be
updated after the resync (or whatever causes the delay).
New projects are obvious because the pages are missing. More
concerning would be missing updates to existing projects because of
this flag. Is there a way to do this without relying on someone to
remember to add the flag yet not cause the circular dependencies?
-Original Message-
From: Joakim Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 12:55 PM
To: Maven Developers List
Subject: Update: Re: [vote] maven release process ( gpg / javadoc /
site / source / remote-resources ) plugins.
Current releases performed...
maven-javadoc-plugin - 2.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-javadoc-plugin/2.2/
maven-source-plugin - 2.0.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-source-plugin/2.0.2/
maven-gpg-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-gpg-plugin/1.0-alpha-1/
maven-remote-resources-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-remote-resources-plugin/1.0-alpha-1/
(dependency) maven-downloader - 1.1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/shared/maven-downloader/1.1/
maven-site-plugin has not been released (yet) as the maven 2.1
dependency has not yet been removed.
jason said that kenney would remove it.
- Joakim
Joakim Erdfelt wrote:
After a chat with Jason about the new release process / staging /
etc...
I feel it is time to get a release out for the following plugins.
maven-gpg-plugin 1.0
maven-javadoc-plugin 2.2
maven-site-plugin 2.0
maven-source-plugin 2.0.2
maven-remote-resources-plugin 1.0
This will allow for the following ...
* release staging.
* gpg signing of all artifacts.
* ${artifactId}-${version}-sources.jar creation
* ${artifactId}-${version}-javadoc.jar creation
* Proper inclusion of the Apache LICENSE and NOTICE files.
I would like to call a vote on getting the 5 crucial plugins released
in a non-SNAPSHOT form.
Once these plugins are in place, the top level parent poms
(maven-parent and apache) can be updated to make these processes
standard for all releases.
To kick things off ...
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
- Joakim Erdfelt
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
See http://www.nabble.com/forum/ViewPost.jtp?post=7884079framed=yskin=177 for full discussion. The problem is that a plugin contains defects that have not yet been resolved in a release. The defect may be fixed in a snapshot version or there may be an unapplied patch available. The releases of your companies artifacts can't use snapshot versions and internally patched versions of the plugins needs to be made available to all developers. My original stab at providing process guidance around this is at http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins. Other people have attempted to follow this and have found shortcomings because the repository for all versions of an artifact is based on that last repository that had metadata for the artifact. e.g. internal_plugins and central both have metadata for plugin X, the repository is set to internal_plugins, which also contains the latest version, and then the repository reset to central. At this point the build process fails because central does not contain the specified version. I can't find any decent use cases for why you want an artifact to be available from multiple repositories. The two I can think of are 1) an artifact moves to another repository, e.g. codehaus to maven. In this case the artifiact id usuallu changes too from a form of name-maven-plugin to maven-name-plugin. So this problem would never have been noticed before. 2) you are creating an internal patch repository. The current work around is to change the artifactId as part of the plugin patching process. I would like the opinion of some maven-devs on this and whether it makes sense to support this better in maven, or to continue with the workarounds available. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Design Best Practices
Issue Subscription Filter: Design Best Practices (37 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles http://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques http://jira.codehaus.org/browse/MNG-612 MNG-1634move maven-core-it to integration-tests http://jira.codehaus.org/browse/MNG-1634 MNG-2125[doc] when and how to define plugins in a pom http://jira.codehaus.org/browse/MNG-2125 MNG-1381best practices: testing strategies http://jira.codehaus.org/browse/MNG-1381 MNG-1563how to write integration tests http://jira.codehaus.org/browse/MNG-1563 MNG-1936pattern: for mojo parameters which have default values in the POM we need standard usage http://jira.codehaus.org/browse/MNG-1936 MNG-474 performance improvement for forked lifecycles http://jira.codehaus.org/browse/MNG-474 MNG-2381improved control over the repositories in the POM http://jira.codehaus.org/browse/MNG-2381 MNG-1950Ability to introduce new lifecycles phases http://jira.codehaus.org/browse/MNG-1950 MNG-1931add a reportingManagement section http://jira.codehaus.org/browse/MNG-1931 MNG-2477Implement repository security improvements for verification of downloaded artifacts http://jira.codehaus.org/browse/MNG-2477 MNG-2642maven-archetype-webapp does not produce Standard Directory Layout http://jira.codehaus.org/browse/MNG-2642 MNG-1305Document Maven's own development process http://jira.codehaus.org/browse/MNG-1305 MNG-1437How to make additions to the POM and have it be backward/forward compatible http://jira.codehaus.org/browse/MNG-1437 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN http://jira.codehaus.org/browse/MNG-1441 MNG-647 Allow Maven 2 to be monitored using JMX. http://jira.codehaus.org/browse/MNG-647 MNG-1867deprecate system scope, analyse other use cases http://jira.codehaus.org/browse/MNG-1867 MNG-367 best practices: multi-user installation http://jira.codehaus.org/browse/MNG-367 MNG-139 server definitions should be reusable http://jira.codehaus.org/browse/MNG-139 MNG-1440Developer Object Model (DOM) http://jira.codehaus.org/browse/MNG-1440 MNG-657 possible chicken and egg problem with extensions http://jira.codehaus.org/browse/MNG-657 MNG-125 guarded mojo execution http://jira.codehaus.org/browse/MNG-125 MNG-1439Organization Object Model (OOM) http://jira.codehaus.org/browse/MNG-1439 MNG-905 review clean repo install of m2 for download trimming http://jira.codehaus.org/browse/MNG-905 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare http://jira.codehaus.org/browse/MNG-1569 MNG-1463best practices: plugin inheritance for a multi project build http://jira.codehaus.org/browse/MNG-1463 MNG-416 best practices: multiple profile deployments http://jira.codehaus.org/browse/MNG-416 MNG-939 specify maven settings from command line http://jira.codehaus.org/browse/MNG-939 MNG-1885Uniquely identify modules by module name and version number http://jira.codehaus.org/browse/MNG-1885 MNG-868 Use uniform format for properties and other tags http://jira.codehaus.org/browse/MNG-868 MNG-41 best practices: site management http://jira.codehaus.org/browse/MNG-41 MNG-140 refactor maven-artifact http://jira.codehaus.org/browse/MNG-140 MNG-1425best practices: the location of configuration files vs resources http://jira.codehaus.org/browse/MNG-1425 MNG-1452best practices: deployment of aggregate JARs produced by the assembly plug-in http://jira.codehaus.org/browse/MNG-1452 MNG-1468best practices: version management in multi project builds http://jira.codehaus.org/browse/MNG-1468 MNG-1423best practices: setting up multi-module build http://jira.codehaus.org/browse/MNG-1423 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update: Re: [vote] maven release process ( gpg / javadoc / site / source / remote-resources ) plugins.
On 14 Dec 06, at 7:00 PM 14 Dec 06, Brian E. Fox wrote:
Does the release plugin deploy the site now?
By default it has for a while. There are default goals (deploy, site-
deploy) if you don't specify any.
Jason.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 14, 2006 5:58 PM
To: Maven Developers List
Subject: Re: Update: Re: [vote] maven release process ( gpg /
javadoc /
site / source / remote-resources ) plugins.
We could add this to release plugin configuration in the parent POM.
On 14/12/2006, at 2:08 PM, Brian E. Fox wrote:
It looks like the -Preporting flag wasn't used when deploying the
sites.
Some of the reports might not be missed, but apparently this also
precludes the goal pages (ex:
http://maven.apache.org/plugins/maven-remote-resources-plugin/
bundle-moj
o.html). I redeployed all the sites listed below so they should be
updated after the resync (or whatever causes the delay).
New projects are obvious because the pages are missing. More
concerning would be missing updates to existing projects because of
this flag. Is there a way to do this without relying on someone to
remember to add the flag yet not cause the circular dependencies?
-Original Message-
From: Joakim Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006 12:55 PM
To: Maven Developers List
Subject: Update: Re: [vote] maven release process ( gpg / javadoc /
site / source / remote-resources ) plugins.
Current releases performed...
maven-javadoc-plugin - 2.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-javadoc-plugin/2.2/
maven-source-plugin - 2.0.2
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-source-plugin/2.0.2/
maven-gpg-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-gpg-plugin/1.0-alpha-1/
maven-remote-resources-plugin - 1.0-alpha-1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/plugins/maven-remote-resources-plugin/1.0-alpha-1/
(dependency) maven-downloader - 1.1
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/
apache/mav
en/shared/maven-downloader/1.1/
maven-site-plugin has not been released (yet) as the maven 2.1
dependency has not yet been removed.
jason said that kenney would remove it.
- Joakim
Joakim Erdfelt wrote:
After a chat with Jason about the new release process / staging /
etc...
I feel it is time to get a release out for the following plugins.
maven-gpg-plugin 1.0
maven-javadoc-plugin 2.2
maven-site-plugin 2.0
maven-source-plugin 2.0.2
maven-remote-resources-plugin 1.0
This will allow for the following ...
* release staging.
* gpg signing of all artifacts.
* ${artifactId}-${version}-sources.jar creation
* ${artifactId}-${version}-javadoc.jar creation
* Proper inclusion of the Apache LICENSE and NOTICE files.
I would like to call a vote on getting the 5 crucial plugins
released
in a non-SNAPSHOT form.
Once these plugins are in place, the top level parent poms
(maven-parent and apache) can be updated to make these processes
standard for all releases.
To kick things off ...
+1 maven-gpg-plugin
+1 maven-javadoc-plugin
+1 maven-site-plugin
+1 maven-source-plugin
+1 maven-remote-resources-plugin
- Joakim Erdfelt
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional
commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Site Plugin
On 12/14/06, Jason van Zyl [EMAIL PROTECTED] wrote:
I have managed to get the site plugin working with 2.0.4 and it
really wasn't a simple matter of rolling back some stuff.
...
Thanks for doing this. But... (you knew it was coming) I'm having
trouble with it when site.xml contains ${modules}. I get this:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...a
ilreader, el-example, scripting-mailreader]\r\n\r\nm... @63:11)
Those are the modules beneath struts-apps, here:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/pom.xml
This is the site.xml:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/src/site/site.xml
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
Jason van Zyl wrote: Yah, I don't buy it. I don't know anyone who uses RPMs to do anything with Java. Actually, if you'll recall our conversations at ApacheCon I mentioned something like that. RPMs make no sense because the ClassLoader can't use them. They also make no sense because the same information should be inside the jar (i.e. a jar and an RPM would essentially be equivalent but use different packaging schemes). However, this is all moot because standard java classloaders don't understand versioning. If they did we wouldn't be having this conversation because, assuming the jar had all the relevant information, it would make no sense to create an RPM as the base OS (i.e. Linux) would have no business managing the contents of a JVM since the JVM is essentially a different OS. I suppose RPMs make sense in the isolated case of the OS actually wanting to start some pre-packaged Java applications automatically. I'm having a hard time how they'd be useful in most other circumstances though. I guess I'd really like to understand how Fedora actually uses Java RPMs in a way that actually works. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
