Re: Interest in Android-based projects?
I've got Masa (Maven Plugins for Android) here: http://code.google.com/p/masa/ which has a pretty solid code-base, if anyone is interested. On Mon, Feb 15, 2010 at 1:22 PM, Santiago Gala santiago.g...@gmail.comwrote: If there is no existing codebase, I would recommend to start as a lab. Once a prototype would be around, going to incubator or looking for TLP status would not be so challenging... Do you have a specific focus area or code base? Regards Santiago On Mon, Feb 15, 2010 at 10:04 PM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Feb 15, 2010 at 12:56 PM, Noel J. Bergman n...@devtech.com wrote: Would there be interest in a project to develop Android-based apps? know that it sounds like an umbrella, and perhaps it would be until we developed some critical mass, but it would provide us with a place to collaborate. --- Noel Sounds interesting... do you have any more details ? Would this be just a place like a Android App Labs where people can come and suggest/start working on new apps ? or would this be something more specific with a smaller scope ? -- Luciano Resende http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Shane Isbell http://twitter.com/sisbell
Re: Incubator Project Dissolution for NMaven
The vote was among the NMaven PPMC. Is it required to have an additional IPMC vote or can we just start wrapping it up, letting the developer community know the next steps? Thanks, Shane On Thu, Nov 13, 2008 at 7:11 AM, Jason van Zyl [EMAIL PROTECTED] wrote: On 13-Nov-08, at 2:23 AM, Niclas Hedhman wrote: On Thu, Nov 13, 2008 at 6:50 AM, Jason Van Zyl [EMAIL PROTECTED] wrote: Do we have an official process for dissolving a project in the incubator? We had a vote amongst the IPMC members for NMaven yesterday and 3/4 IPMC members voted to dissolve the NMaven project and take it out of the incubator. Uhhh I have not seen any vote regarding NMaven in the Incubator PMC. I must assume you meant PPMC or perhaps even Maven PMC. Sorry, the NMaven IPMC. Is there any official process or do we just update the documentation? I think that you have Incubator PMC consensus, so unless someone yells, documentation needs to be updated. Off my head; * STATUS page - Add a note that it is retired. * Website (if any), saying that Incubation retired. * site-author/stylesheets/project.xml - Remove NMaven link. * site-author/projects/index.xml - Move it to Retired section. * Reporting Schedule - http://wiki.apache.org/incubator/ReportingSchedule Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reports Overdue for: Abdera, NMaven, WSP4J, XAP
Just updated NMaven. Thanks, Shane On Sun, May 18, 2008 at 7:39 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: I see activity on the mailing lists for all of these projects, and see active Mentors ... so where are the reports? I will not be readily available to pick up changes tomorrow morning, so we need them now. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache NMaven 0.15-incubating Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Apache NMaven team is pleased to announce the release of NMaven 0.15-incubating. NMaven provides Maven 2.x plugins to support building of .NET applications. http://incubator.apache.org/nmaven/0.15/ Features for this release include: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms - -- The Apache NMaven Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfoXGkACgkQXJIdCxe4X/QMbQCgh5KSiJfDKxoMd7qTDamIwy8R hvgAoId9K4gy+bx2bMMUGSJatE5JpCnL =Fap3 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] (2) Release NMaven 0.15-incubating
We have a new vote going on to release NMaven 0.15-incubating. I've addressed most of the issues raised in the last vote on [EMAIL PROTECTED] Rather than serializing the votes across the PPMC and the IPMC again, I'd like to just have one vote. You can find the ongoing vote here: http://www.nabble.com/-VOTE--%282%29-Release-NMaven-0.15-incubating-td15575008.html Thanks, Shane
[VOTE] Release NMaven 0.15-incubating
On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ Thanks, Shane
Re: [VOTE] Release NMaven 0.15-incubating
Hi Sebb, Thanks for checking over the staging release. The only missing license headers that I could find are in the unit test and integration test source files. Do test class files also need the license header? Thanks, Shane On Feb 18, 2008 10:59 AM, sebb [EMAIL PROTECTED] wrote: On 18/02/2008, Shane Isbell [EMAIL PROTECTED] wrote: On the NMaven dev list, we have passed a vote for our first release. We request approval of the release by the IPMC. The 0.15-incubating version supports: 1) Compiling C# projects (2.0 framework) 2) Strong Naming 3) Generation of assembly info based on pom metadata 4) Support for Microsoft and Novell/Mono platforms Staging repo: http://people.apache.org/~sisbell/staging_repo/ The NOTICE files in the jars don't agree with NOTICE.txt in SVN, in that the Copyright says 2002-2008, whereas NOTICE.txt says just 2007. Did the project really start in 2002? Also, the NOTICE file is only supposed to include details of code that is included in the distribution - not any external dependencies. The proper heading is: This product includes software developed by 'etc' There is no need to itemise the individual projects within ASF. See http://www.apache.org/legal/src-headers.html#notice for details. The individual jars seem to have individual NOTICE file headings, e.g. in maven-archetype-windows-application-0.15-incubating-sources.jar the heading reads: maven-archetype-dotnet-windows-application Copyright 2002-2008 The Apache Software Foundation Surely the official name of the project is Apache NMaven ? Unless there is some non-ASF code included in the distribution, then the NOTICE.txt file currently at the root of SVN is all that is needed for the NOTICE in the jar files. == The Manifest.mf files in binary jars should ideally contain the Java compiler source and target versions. There's no need for the .asc.mdf and .asc.sha1 files - an .asc file is only needed to verify the file sig, and if the .asc file is mangled it won't agree with the file it is protecting. Vote Thread: http://www.nabble.com/-VOTE--Release-NMaven-0.15-incubating-td15447003.html 4 +1 binding (PPMC), 1 +1 non-binding 0 0/-1 Tag: http://svn.apache.org/repos/asf/incubator/nmaven/tags/maven-dotnet-parent-0.15-incubating/ NOTICE.txt says: Copyright 2007 The Apache Software Foundation That should be Copyright 2007-2008 The Apache Software Foundation - assuming that the project started in 2007. There should ideally be a LICENSE file alongside the NOTICE file. Some of the source files are missing the standard ASF header. Thanks, Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Projects in trouble or otherwise needing help
I just updated the belated board report for NMaven. Apologies. I checked out the board reports site on Friday, saw the Nov. 14th deadline and then closed the browser. Regards, Shane On Nov 12, 2007 8:47 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: It appears that we have a number of projects to discuss: NMaven - mailing list shows steady activity. XAP - mailing lists show almost no discussion, mostly JIRA issues and commits WSRP4J - burst of activity during the Summer, nothing since. The issues do not appear to be the same in all cases. I had to review the archives, since there were no board reports. --- Noel - 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]
[PROPOSAL] JVending
Hi, I have a proposal to bring over JVending to the Apache incubator. I have put a good deal of work into this project over the last few years, but it is languishing on Sourceforge due to lack of community interest. I've seen what the incubator has done for the NMaven podling; I would like to breathe similar life into JVending by using the incubator to generate interest, build a community and recruit good developers. I'd like to see if there is any interest from the Apache community in getting JVending fully compliant with JSR-124 and passing the TCK, as well as subsequent work on the portal and various adaptors. I have also been reading about some of the new work with Product Line Architectures coming out using JVending: this could be an important area of growth for social networks and the delivery of content, and another area of focus for JVending. Currently, there are no other developers; I am in need of mentors and committers. Proposal Link: http://wiki.apache.org/incubator/JVendingProposal Thanks, Shane Isbell = JVending Proposal Abstract JVending is a content provisioning system that implements most of the J2EE Client Provisioning Specification (JSR-124). Proposal JVending is a content provisioning system that implements most of the J2EE Client Provisioning Specification (JSR-124). It provides catalog management, device detection and Web/WAP based browsing. It is designed to run on embedded servers and DBs, as well as within more traditional carrier systems and deployments. Background The mobile application space deals with numerous handheld devices, each with different capabilities. It's a challenge to match content requirements - such as screen size, MIDP version, and memory - to an appropriate device. The JSR-124 expert group addressed these issues by creating a specification that defined how to match content requirements to device capabilities. The specification also covers discovery of content, stocking of content and delivery adapters for provisioning. While the specification arose to address pain points within the mobile industry, the specification covers all content and all devices (including PCs). JVending initially arose from a desire to demonstrate the basics of DRM and OTA provisioning, but later developed into a fully functional provisioning server based on the JSR-124 spec. An early goal, maintained throughout the life of the project, has been to build a provisioning server that is light enough to deploy on PCs so that the individual can participate in the sharing and publishing of content. Rationale JVending is the only open-source version of JSR-124. While there are a number of other content repositories, JVending is the only one specialized for general capability matching and custom interactions to the device, making it highly extensible. For example, users can easily create custom interfaces - SOAP, RDF, HTTP, OTA - that sit on top of a common repository with advanced device capability matching. In my case, I recently developed a Maven adapter to deliver artifacts to the build machine. There is also exciting, new work in Product Line Architectures that integrates JVending with Scatter for matching devices and applications across millions of variants. This has important implications for social and location aware content delivery. ASF would be a good home for JVending due to the ASF's emphasis on community building, which is an area that has been enormously difficult to do on sourceforge. Initial Goals - Change code base to ASLv2 - Import code base to incubator SVN - Remove LGPL Hibernate dependencies - Recruit developers Current Status JVending implements most of the JSR-124 spec but has not been tested with the TCK. The last release of JVending provisioning J2EE component was April 2006. There has been subsequent work related to integrating with WURFL and adapters for provisioning of Maven artifacts. No active work is going on at this time. Meritocracy There is currently only one developer on the project. Additional developers will be added by following the Apache meritocracy process. Community Various companies have expressed interest in deploying JVending but no active community has involved in its development or use. Given the current trends in self-publishing of content, there is a large potential base of users and developers, particularly those wanting to deliver personal content to mobile devices. Also, since JVending is implementing a JSR spec, I expect there to be interest in commercial developers wanting to leverage open standards in the provisioning space. The goal is to attract 3-5 developers from different companies/organizations to sustain the project. Core Developers Shane Isbell, who is the only developer on the project, founded JVending. Alignment JVending currently has dependencies on Apache projects jaxme for processing of configuration files and Lucene for content search. It is packaged as a WAR file and runs on Tomcat. It also
Re: [POLL] Incubator Maven Repository
Just to clarify, the implementation is now as follows: NMaven uses the default repo format remotely and then transforms locally; this is the most pragmatic approach, and I don't have any immediate concerns. The problem, however, is that we are exposing the internal schema to the client; this creates a fair amount of confusion as people look for a general schema that satisfies the various languages, as opposed to a general API, say through REST or SOAP. Although HTTP GET with a URL may qualify as an API, under its current form its really implementation (file-system) specific. I would be surprised if this issue doesn't keep coming up, as people become interested in using Maven for other languages. Shane On 5/15/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote: I didn't have a chance to talk about this with Shane but the idea in the end is to make the repository agnostic on how things are stored and how the client uses them. Right now is a simple directory, but could be a database with a web front end or anything like that. It shouldn't matter how NMaven artifacts are stored, as long as the client handles them correctly. A solution we talked about time ago was to put them as any other artifacts and either developers could choose what format their local repo is in or the pom could say how they should be stored It all boils down to packaging that's important. It doesn't matter how they are stored. What matters is how they are transformed and I'm sure someone can find a work around for having the name in the assembly manifest being burned in and breaking the linker when the file name and manifest entry doesn't match. The repository can theoretically be stored in anything Wagon supports but it's unlikely we'll stray very far from file-system based mechanisms. But this is a total different discussion On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote: Shane, Honestly, it sounds like the NMaven stuff will need a complete new set of repositories for NMaven artifacts. There isn't any way, IMO, that the repo layout can change for the normal maven 1 and maven 2 repositories. Incubator or repo1.maven.org is relatively irrelevant in that regards. The layout is pretty much set in stone. There are too many plugins (deploy, etc...) that rely on it, there are too many other apps (several different proxy applications, etc...) that rely on it, etc... If the current layout is inadequate for NMaven, the NMaven team should figure out an appropriate place for a new repository. My personal suggestion is to work with the Maven team and create a new area at repo1.maven.org/nmaven or similar. But that's me. In either case, I think that discussion is separate from where the m2 artifacts go. It make make sense to put the nmaven stuff in dist/incubator for a while until the layout is finalized, then move to central.However, the layouts for m1/m2 are finalized. Thus, they can/should go to central. (IMO) That said, I don't know the NMaven details. But my #1 concern is your line: I would expect that an incubator release repo would be more amendable to such changes. No chance, IMO. Once an artifact is released, it's SET IN STONE. That includes the layout of the repository it's sitting in. Once theres the possibility that another project is relying on a particular artifact to be living at a particular location, it needs to stay there. The incubator m2 release repository is no different from central in that regard. Dan On Sunday 06 May 2007 14:11, Shane Isbell wrote: [ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories
Re: [POLL] Incubator Maven Repository
Hi Noel, Correct, using a URI does not require a specific implementation; but in today's environment, if someone needs a different repo format, they get one of two responses: 1) create your own repo that uses a different repo format; or 2) use the same repo format but transform the artifact names. Thus, the repos - as they exists within the community - are, for all effective purposes, implementation specific: none of them can be used for custom formats. Thus the API is adequate, but the implementation may prove problematic in the long run. I decided to go with option 2; but the point is that this issue will keep coming up as developers add new languages and require new formats. Regards, Shane On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Although HTTP GET with a URL may qualify as an API, under its current form its really implementation (file-system) specific. What makes it implementation specific? You can't store the files in a DB, and map the URI to the resource? Isn't it really a URI, specifying the package name and version? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Incubator Maven Repository
[ ] use standard repositories [ x ] relocate repositories under /www.apache.org/dist/incubator My reasons are as follows: First, NMaven does not follow the standard repo layout; second, the repository layout structure is still in a state of flux, meaning that there is a need for potentially changing the layout for .NET artifacts, while still doing releases. Getting more into some more specifics, with NMaven, there is no version information contained within the artifact file name and the version must follow a standard 0.0.0.0 format. This precludes the use of incubator within the version itself. As mentioned above, at this early stage, it's also not 100% clear on exactly how NMaven .NET artifacts will reside within the repo. For instance, there is an open question as to where pom files will reside when we add the concept of classifiers to the repo. Also, given the repository layout structure for NET artifacts may change over time, as the incubator project evolves, I have concerns whether any of the standard maven repos would accept - and with good reason - an NMaven incubator release at all. I would expect that an incubator release repo would be more amendable to such changes. Shane On 5/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote: [ x ] use standard repositories [ ] relocate repositories under /www.apache.org/dist/incubator Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] NMaven podling
Hi Noel, The project is going well and as such, should not be archived. I have not reported for April since the NMaven schedule occurs on the February, May, August, November schedule. Thanks, Shane On 4/23/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Is this project going, or should it be archived? --- Noel -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 2:25 To: general@incubator.apache.org Cc: Shane Isbell Subject: [PROPOSAL] NMaven podling Hi, The Maven PMC has voted to accept NMaven for incubation (see [EMAIL PROTECTED] on [EMAIL PROTECTED]). The full proposal is attached below, and can be viewed here also: http://maven.apache.org/proposals/incubator/nmaven.html I'm posting this here for any feedback or objections from the incubator PMC. I'll give it 5 days (to include the weekend) before going ahead. If there are no objections after that, since the Maven PMC has already voted to accept it and we have 3 incubator PMC members listed on the proposal, I will go about getting the status file in and the allocation of resources started. Cheers, Brett
