Re: [VOTE] Publish Apache Sling Release
> > > > I don't think it's OK to expect users to have to trawl through all the > NOTICE and LICENSE files to find all the required information. IMO, > the top-level L & N files need to relate to the entire contents. > Transitively or just for the first level dependencies?
Re: [VOTE] Publish Apache Sling Release
On Wed, May 13, 2009 at 6:04 AM, sebb wrote: > On 13/05/2009, Jukka Zitting wrote: > > Hi, > > > > > > On Wed, May 13, 2009 at 12:09 AM, sebb wrote: > > > Of course external dependencies - to first level at least - *ought* to > > > be documented to ensure the consumer knows what else is needed to use > > > the product, but they go elsewhere, e.g. in the README and/or on the > > > web-site. > > > > > > A Maven-based project documents all it's dependencies in the POM. > > > > Or possibly not, if the project use a parent POM. > > It is not fair to expect users to understand the contents of POMs. > There's some automated tooling to insert the list of dependencies alongside the notice and license files inside jars, but it's not used in all cases. I haven't looked into why yet. > > > BR, > > > > Jukka Zitting > > > > - > > 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 > >
Re: This problem of mine
> > > What I don't get is why would anyone want to keep the name if there > are potential overlaps or troubles ahead? My thoughts exactly. > > I mean, there are probably better (coding) and harder (releasing, > graduating) things to do than getting stuck about the name. > Why don't you (as a podling) simply move on with another cool name, > for example, just brainstorming here... "JSecurity"... or something > similar? > +1
Re: asc.md5 and asc.sha1 (Was: [VOTE] Release OpenWebBeans 1.0.0-incubating-M2(Third Try))
Agreed, there's no harm here, and they are tiny files. The deploy plugin adds hashes to all files that pass through it so it would need special logic to ignore these files. On Mon, Jun 1, 2009 at 12:38 PM, Jukka Zitting wrote: > Hi, > > On Mon, Jun 1, 2009 at 9:21 PM, sebb wrote: > > The .asc.md5 and .asc.sha1 files should be deleted from the plugins > > directory tree before deployment, as they serve no useful purpose. > > These files are automatically produced by the interaction between > Maven and the Maven GPG plugin. The proper way to get rid of them > would be to fix this in Maven and/or the GPG plugin. I'm not sure if > someone is already working on this in. > > Until then I don't see much point in adding special deployment steps > just to get rid of those files. The extra files cause little damage > and the cost of a more complicated deployment process or script > probably outweights the benefits. > > BR, > > Jukka Zitting > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Apache JSecurity/Ki Project Rename - Final Vote
+1 Apache Shira On Fri, Jun 5, 2009 at 6:40 AM, Jeremy Haile wrote: > +1 Apache Aseca > > I like the alliteration - it rolls of the tongue a lot easier than Apache > Shiro IMHO. > > - > 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
Re: incorrect terminology: lead developers
The project's PMC is the leadership...it's not devoid of leadership. On Mon, Aug 10, 2009 at 11:23 PM, Greg Brown wrote: > OK, then I'll try to provide more clarification. I don't understand how a > project without leadership can succeed. I don't care what you call it, > someone needs to drive the process. I'm not talking about an implication of > authority or a higher degree of ownership - I'm talking strictly about > making things happen. If that's not a "leader", then what is it, in ASF > terms? > > Note that "leader" does not necessarily mean "singular" (i.e. "dictator"). > Most projects have multiple leaders. IMO, a project without a "leader" (or > leaders), will go nowhere. > > G > > On Aug 10, 2009, at 11:18 PM, Joe Schaefer wrote: > >> >> - Original Message >> >>> From: Greg Brown >>> To: general@incubator.apache.org >>> Sent: Monday, August 10, 2009 11:12:36 PM >>> Subject: Re: incorrect terminology: lead developers >>> We don't have a notion of fixed leadership at Apache. Leadership is always welcome but it is determined by the will of the group in question at a given point in time, not based on one's official status. We try to avoid status symbols in order to retain the fair balance of individual decision making within our projects. >>> >>> Of course. My issue is with the idea that a project can be successful in >>> the >>> absence of any kind of leadership. So maybe some clarification on >>> terminology is >>> in order... >> >> I thought David's explanation that we don't us the phrase "project leads" >> at Apache was fairly straightforward ;-). >> >> >> >> >> - >> 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 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
> What is happening in some Java projects, via Maven's release plugin, > is disturbing since the "source release" only exist in the subversion > repository This problem has been solved and is no longer valid. Any repetition of the old news is total fud. We have for many months now been providing proper source releases for EVERYTHING in the maven project and just recently promoted the same to the Apache pom making it automatic for any Apache project with the new pom. See links below for more info: http://old.nabble.com/Update-on-ASF-Release-requirements-ts23379350.html#a23379350 http://old.nabble.com/-VOTE--Apache-%28parent-POM%29-version-7-ts26221188.html As far as I understand the requirements, this issue is completely resolved so lets stop saying that Maven produces incorrect releases. It was never an issue with the tool itself, but as a project we've fixed it and are sharing it to all projects at Apache using Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Wed, Nov 11, 2009 at 5:50 PM, Davanum Srinivas wrote: > I think this is a pretty important issue worth "spamming" but whatever > I think it's worth noting, I've had several projects asking for it to be available so they can use it and ditch their homebrew solutions. When it's promoted to the repo, I'll send a notice. Dan, perhaps on the maven dev list, I'd like to understand why it won't work for cxf...but fwiw, we made it possible to replace the default descriptor bundle with your own so hopefully even if we can't make the descriptor work for cxf, the rest is still applicable. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
> Why not sent it through bo...@? All Chairs are subscribed to that > list, several board members have in the past raised concerns about the > releases created using maven. This would unequivocally show that maven > has delivered a working solution, and notify all PMC chairs of the > general Apache parent pom. They are responsible for communicating that > with their own community IMO if it is applicable. > Well, I feel like if I email board@, then I should be talking to _the board_ and not everyone else in the room. The promotion of this release would naturally be noted in the next board report, as where the previous changes when we made them inside the maven project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Request PMC Karma for IP Process
I'm following the checklist at: http://incubator.apache.org/ip-clearance/ip-clearance-template.html for clearing a submission of the Nexus Indexer code to the Maven Project. 1)IP Clearance processing must be executed either by an Officer or a Member of the ASF. If you are not an Officer or a Member, please contact your project chair who will find an appropriate volunteer. Incubator karma is also required. Please request karma from the incubator pmc if you do not have it. So I hereby request incubator pmc karma. Thanks, Brian Fox Apache Maven PMC Chair - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
IP Clearance question
Question on Step 3: A software grant must be provided to the ASF. This grant can either be done by the ASF Corporate CLA (via Schedule B) or the traditional License Agreement. Acceptable methods of sending the grant to the ASF includes: snail-mail to the ASF office and/or ASF officer FAXing to the ASF office and/or an ASF officer Emailing the scanned document to secret...@apache.org and legal-arch...@apache.org. Sonatype already has a CCLA on file and all the active committers are already Maven Committers. Do we need to file any additional paper work or is this step covered? --Brian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance Question
So as I understand it, the old copyright can exist in the NOTICES file and that's ok in conjunction with the standard Apache license headers & copyright? On Tue, Feb 2, 2010 at 2:10 PM, Robert Burrell Donkin wrote: > On Mon, Feb 1, 2010 at 11:47 PM, Niclas Hedhman wrote: >> I think this will be promoted now, after the recent license header >> issues in another podling... > > +1 > > once i have a minute, i planned to drawing up additional policy > > - robert > > - > 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
Re: Request PMC Karma for IP Process
Misread on my part. Thanks. On Mon, Feb 15, 2010 at 1:01 AM, Noel J. Bergman wrote: > Brian Fox wrote: > >> 1)IP Clearance processing must be executed either by an Officer or a >> Member of the ASF. If you are not an Officer or a Member, please >> contact your project chair who will find an appropriate volunteer. >> Incubator karma is also required. Please request karma from the >> incubator pmc if you do not have it. > >> So I hereby request incubator pmc karma. > > As a PMC Chair, you should already have the SVN karma. If not, we need to > fix the ACL. So unless you are asking to join the PMC, you should have been > set to go. > > --- Noel > > > > - > 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
Re: Third party Maven Repository Usage
At the Central repository we are restricting the inclusion of external repositories because this generally creates a mess. This is being enforced on new artifacts coming in so I would recommend you do not add them or your artifacts themselves will end up blocked. A better choice is to encourage the missing dependency projects to get their stuff into Central, or find some compatible libraries that are. On Mon, Mar 8, 2010 at 11:50 AM, Gurkan Erdogdu wrote: > Hi; > > Is there any rule/policy for using third-party maven repositories in our > project poms? Recently, we have required to list some repositories in > settings.xml (for example: jboss) to our codebase built correctly. But when > Apache-Hudson runs to built daily, it throws errors because of not finding > required repositories. Is it OK to list those repositories in our poms? > > I have just found > http://maven.apache.org/guides/mini/guide-central-repository-upload.htmldocumentation > FAQ and common mistakes section. > > Thanks; > > --Gurkan > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Third party Maven Repository Usage
>> Interesting. That's news to me... You have a pointer to more information? > As it turns out, almost all references to external repositories in poms are junk or turn out to be junk after a bit of time. See here for some examples: http://www.sonatype.com/people/2010/03/why-external-repos-are-being-phased-out-of-central/ > * Unclear from the documentation is if this restriction on external > repositories is limited to only the repository definitions in a pom, or if > it is (or will be) extended to dependency resolving as well. > If not all dependencies can be resolved to Central itself, would that be > "flagged" too and also cause blocking the artifact(s) ? The validations are currently configured to disallow any release repository declarations in the poms. We may allow some approved external repos down the road if the contents are vetted and cleaned and unlikely to disappear. The main issues revolve around fly-by-night or unreliable repositories. Having these in your poms is a red herring and end up causing your users more harm than good. > > * At what stage is this policy "enforced"? I'm thinking of Apache Repository > when we deploy and release. Would a violation of this policy already be > noticed (and reported) while doing a staging release, or only at the final > release to Maven Central? This is enforced by the Nexus staging rules in the various forges and ultimately will be applied to all avenues into Central regardless of the source. (Rsyncs are being phased out). I have not enabled this rule on repository.apache.org but it is in place in most other locations. I wanted to be able to analyze the external repo use of Apache based projects and work with them before throwing down a new gauntlet. No panic is necessary, we'll work this out together, but this is a rule that is going into effect at Central and all projects, Apache or not will eventually have to pass the same criteria. > The latter clearly would be too little too late IMO. > Note: we're using Apache Repository for snapshot deployments right now, and > I haven't seen any "warning" about us referencing external repositories. This currently wouldn't trigger on any snapshot builds, but would prevent the promotion of a staged repo, exactly how you can't promote artifacts that aren't signed. Again, it's not enabled and I don't intend to enable it until I can analyze and work with projects to make this a non issue. > > * Does this new policy also affect the processing and handling of the > "legacy" rsync repositories at /www/people.apache.org/repo? As it will affect all sources into Central, yes this would eventually affect the legacy repo as well. However... > If it does, or even only partly, please let us know how and to what extend. > Note: we're planning a bugfix release shortly of an older version of > Jetspeed-2, version 2.1.4 (Apache Portals). > That version of Jetspeed-2 doesn't and cannot use the new Apache master pom > nor Apache Repository as it would require too major changes for the whole > project configuration itself. The current Jetspeed-2 version 2.2.0 has been > released through Apache Repository, and we're planning a new release 2.2.1 > shortly too. However, for Jetspeed 2.1.4 we'll still have to use the > "legacy" rsync procedure. When a project is moved over to the new repo, the legacy repo is disabled for that project. Meaning you won't be able to deploy there anymore. Central can't rsync the same project from two locations and expect the metadata to be correct. To deploy into r.a.o, you won't have to use the entire new master pom, just change the url in your distributionManagement. Just ping me and I'll be glad to help you out with this. > > * A policy change like this will IMO affect and *restrict* any and all > Apache maven build based projects who want or are supposed to deploy to > Maven Central. *Apache* policy does not in any way restrict (maven) > dependencies on external repositories as long as the ASL license is honored. > For whatever reason, this new Maven Central policy now seems to require all > external dependencies be (at least also) be available from it. This affects all artifacts in Central not just Apache. We're doing it to improve the ecosystem, take a look at my blog referenced above and you'll see why this is a critical issue to be resolved. > What about other, generally respected and IMO also fine repositories like > http://download.java.net/maven/2 ? Have you actually looked at the contents there? We have and frankly it's a disaster. The good news is we're working to clean this up and get all those artifacts into Central as well. The sky isn't falling here and we aren't going to do anything to harm the community, this is an effort to move towards a more sustainable model. My answer was in response to the initial question of should they use external repositories and I simply wanted to point out that they should avoid going down a road that will have to be unwound in the near future.
[IP Clearance] maven-indexer
The indexing code from Sonatype Nexus has been donated to the Maven project. The completed form is here: http://incubator.apache.org/ip-clearance/maven-indexer.html (once the site refreshes) Lazy Consensus validates the clearance in 72hrs - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP Clearance] maven-indexer
I'll consider this passed and proceed to commit the code. Thanks, Brian On Mon, Apr 19, 2010 at 10:00 PM, Brian Fox wrote: > The indexing code from Sonatype Nexus has been donated to the Maven > project. The completed form is here: > http://incubator.apache.org/ip-clearance/maven-indexer.html (once the > site refreshes) > > Lazy Consensus validates the clearance in 72hrs > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Shiro version 1.0.0-incubating
This looks correct to me. The way it's setup with the apache parent pom is that the root module will have the fully buildable source, all the individual modules still have their source and jdocs for ide integration. On Wed, May 26, 2010 at 12:39 PM, Les Hazlewood wrote: > On Wed, May 26, 2010 at 8:11 AM, ant elder wrote: > I can't find all the source for the release. AFAICT the only way to recreate all the release artifacts would be from the svn tag but thats not enough as an ASF release must include a source release. If I've just missed it and all the source is there somewhere then could you provide the link? > > It is part of the staging repo under the provided URL: > > https://repository.apache.org/content/repositories/orgapacheshiro-005 > > Specifically, the complete buildable source package is here: > > https://repository.apache.org/content/repositories/orgapacheshiro-005/org/apache/shiro/shiro-root/1.0.0-incubating/ > > Les > > - > 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
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Why are there two binary release directories? The 017 one only seems to have one archive (.bz2) in it, the rest of the files are hashes or signatures (and even some hashes of sigs, which could be safely deleted, as they serve no purpose) Vincent, if you do multiple mvn builds that should go into the same staging folder, just don't close the first one between builds. Nexus will see these all and put them together into the same repo. But once it's closed, it's closed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Gotcha, that's unusual i hope since we use ip as part of the uniqueness to sort out potentially simultaneous incoming deployments. Vincent Siveton wrote: Hi Brian, 2009/4/26 BRIAN FOX : Why are there two binary release directories? The 017 one only seems to have one archive (.bz2) in it, the rest of the files are hashes or signatures (and even some hashes of sigs, which could be safely deleted, as they serve no purpose) Vincent, if you do multiple mvn builds that should go into the same staging folder, just don't close the first one between builds. Nexus will see these all and put them together into the same repo. But once it's closed, it's closed. Nope, just one time but my provider changed my IP during the release process. Cheers, Vincent - 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
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Multiple hosts can share a public IP address. This is often the case for organisations with many hosts on their internal Lan - all the hosts (there could be hundreds) will appear to have the IP address of the internet gateway. But this is getting a bit off-topic. IP is only part of how staging works. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Niclas Hedhman wrote: On Tue, Apr 28, 2009 at 1:14 PM, Jason van Zyl wrote: Not mocking, just clarifying that on the aggregate level what is distributed via the standard Apache mechanism easily has its analog source equivalent which can be built. Ok, I think we are in general agreement. Are you personally of the opinion that -sources.jar are not adequate as formal ASF releases? I have the opinion it is currently not, but I don't mind seeing a change... There are changes that can be made to the ASF pom to produce the bundles that will meet the requirements. These changes will have a better chance of being made if concerns are brought to the Maven dev team. I just now learned of the month long discussion on legal-discuss via this thread in incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
In the time you've spent talking about the problem -- and not with anyone who could probably fix it -- you probably could have altered the organization wide POM to make the assemblies you desire. Not that I'm aware of the concerns, I've started an additional thread at legal-discuss because at a minimum the currently documented information is insufficient imo and there are additional clarifications required that will dictate how we approach this problem. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
Henning, I asked some specific questions on the source release over at
legal-discuss, can we consolidate the requirements gathering over there?
Henning Schmiedehausen wrote:
Calm down, Jason. No one was attacking Maven.
The Apache Software Foundation requires a project (not just an incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible. Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to users
by downloading an artifact from our servers through www.apache.org/dist and
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the tarball that
I can go into and say (be it ant, maven or make) and get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
wrote:
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
-1.
As others have pointed out, the ASF releases Open SOURCE, not Open
Binaries and part of the policy is that the distributed artifact is
first and foremost a buildable source tarball. Without it, it is not a
release.
You may have system requirements ("thou shalt need Maven 2.0.6 or
2.0.9" ) and you should provide full build instructions to produce the
projects binary. And if you distribute a binary, it should be the same
thing that gets produced by following your instructions.
And the above is not really up for debate either. At the end of the
day, people will rely on tarballs, checksums (download integrity) and
signatures (manipulation integrity), and those are the primary
artifacts that Apache Infrastructure will archive and get mirrored
around the world.
Maven artifacts are really nice to have for Maven users, but is
exactly that; "Nice to have".
Now, you are free to go banging on Maven's door that their built-in
workflow doesn't support the Apache policy very well.
Don't spread FUD like that. You don't have any idea how Maven releases work
so I'll take a moment and explain it to you.
For a release like Maven we have N modules, where each module produces a
JAR, and each of those is released. Each JAR carries with it the POM inside
it, but is in a form which can be automatically utilized by IDE integration
to automatically be downloaded and integrated with debuggers. All the legal
bits are in the JARs and legally intact as it were. The blue print to
actually build that individual JAR is in the JAR by default in Maven. You
can't just unpack that source JAR and build it and that's for a couple
reasons: the first is that it's generally useless and the second is that we
create a source archive of the entire release with all the modules which is
what we recommend. As with Maven, the tagged sources for the build are
distributed along with the binaries. This is a matter of setting up a source
assembly, not hard to do.
That said, show me any non-Maven project that makes individual JARs that
have the capability of rebuilding themselves. There aren't any here at
Apache. What gets produced is a overall source archive. And show me anything
as advanced and useful to developers where grabbing the source JARs for
debugging is transparent or materializing sources from binary artifact
coordinates is a button click. Again, nothing does that besides Maven and
the corresponding IDE integrations. So Maven adheres to any standard for the
overall release but goes way above and beyond to actually produce something
far more useful for actually doing work.
So please don't try to explain to people what Maven does when you don't
actually understand it yourself. What gets released as the N modules is
complementary to aggregate release which is compliant with Apache. So if
Shindig doesn't have the overarching source archive that's not hard to add.
But there is not a single non-Maven build at Apache where a JAR emanating
from multi-JAR build where that JAR carries with it the information to build
itself. You are confusing an aggregate release with the releases of the
individual components which is what Maven users need to consume. We account
for both for the case where a user grabs the distribution to use, and the
case where someone is building a Maven plugin (most often in an IDE where
Re: [VOTE] Approve the release of Shindig Incubator 1.0
but again that wouldn't qualify as what
Henning described as 'a tarbal of the svn tag'.
Now if it's a requirement, and one that I can fully understand, that the
'source archive' should be usable as to rebuild release archives,
This is what I'm trying to drive some consensus to and get documented.
The requirements should be clarified before we attempt to devise a
solution because the requirements would apply to all Apache releases.
I'm sure
it's not a lot of effort at all to bring back the source archive option. and
we'll gladly live with the few slightly confused end users if that is what
it takes to get our incubating release done by the book.
-- Chris
On Tue, Apr 28, 2009 at 8:50 PM, Henning Schmiedehausen
wrote:
Calm down, Jason. No one was attacking Maven.
The Apache Software Foundation requires a project (not just an incubator
podling. All projects) to release source in a form that can be used to
recreate the binaries.
For the current state of the Shindig release, this is not possible. Noone
was saying anything else.
For Apache, we release source code that is immediately consumable to users
by downloading an artifact from our servers through www.apache.org/distand
potentially be able to rebuild the artifact.
In general, this is a tarball / zip of the contents of a Subversion tag.
Everything beyond that is
- optional
- a convenience to our users
This especially goes to
- binary archives (whether these are .jar archives in Java or Binary builds
for a platform in non-Java land)
- source/javadoc in another, better consumable form for IDEs
Supporting these is nice to users, but the required part is the tarball
that
I can go into and say (be it ant, maven or make) and get
something that can be used.
This is not the case for Shinig in its current state. Whether this is
acceptable or not to the Incubator PMC members is another question.
Ciao
Henning
On Mon, Apr 27, 2009 at 09:49, Jason van Zyl wrote:
On 26-Apr-09, at 8:25 PM, Niclas Hedhman wrote:
On Mon, Apr 27, 2009 at 6:46 AM, Vincent Siveton
wrote:
You need to do a checkout of the tag to build it.
The source artifacts provide only java source, no build file.
-1.
As others have pointed out, the ASF releases Open SOURCE, not Open
Binaries and part of the policy is that the distributed artifact is
first and foremost a buildable source tarball. Without it, it is not a
release.
You may have system requirements ("thou shalt need Maven 2.0.6 or
2.0.9" ) and you should provide full build instructions to produce the
projects binary. And if you distribute a binary, it should be the same
thing that gets produced by following your instructions.
And the above is not really up for debate either. At the end of the
day, people will rely on tarballs, checksums (download integrity) and
signatures (manipulation integrity), and those are the primary
artifacts that Apache Infrastructure will archive and get mirrored
around the world.
Maven artifacts are really nice to have for Maven users, but is
exactly that; "Nice to have".
Now, you are free to go banging on Maven's door that their built-in
workflow doesn't support the Apache policy very well.
Don't spread FUD like that. You don't have any idea how Maven releases
work
so I'll take a moment and explain it to you.
For a release like Maven we have N modules, where each module produces a
JAR, and each of those is released. Each JAR carries with it the POM
inside
it, but is in a form which can be automatically utilized by IDE
integration
to automatically be downloaded and integrated with debuggers. All the
legal
bits are in the JARs and legally intact as it were. The blue print to
actually build that individual JAR is in the JAR by default in Maven. You
can't just unpack that source JAR and build it and that's for a couple
reasons: the first is that it's generally useless and the second is that
we
create a source archive of the entire release with all the modules which
is
what we recommend. As with Maven, the tagged sources for the build are
distributed along with the binaries. This is a matter of setting up a
source
assembly, not hard to do.
That said, show me any non-Maven project that makes individual JARs that
have the capability of rebuilding themselves. There aren't any here at
Apache. What gets produced is a overall source archive. And show me
anything
as advanced and useful to developers where grabbing the source JARs for
debugging is transparent or materializing sources from binary artifact
coordinates is a button click. Again, nothing does that besides Maven and
the corresponding IDE integrations. So Maven adheres to any standard for
the
overall release but goes way above and beyond to actually produce
something
far more useful for actually doing work.
So please don't try
Is Jfuzzylite incubating?
I can't find any references on this list, but I got a request to create a repo. https://issues.apache.org/jira/browse/INFRA-9480 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [IP CLEARANCE] Maven Wrapper
I think what Robert is highlighting was that collectively, the contributors are still owners and have granted permission to use another license. On Mon, Feb 3, 2020 at 4:59 PM David Nalley wrote: > > On Mon, Feb 3, 2020 at 9:27 PM Justin Mclean wrote: > > > > HI, > > > > I agree with what John wrote, part of the code is EPL which is not > > compatible with the ALv2, you need the owner permission to change the > > license on that.. > > > > My understanding of "Let me try to get in contact with Walmart Labs to get > > an SGA for the Takari Maven Wrapper.” was that the next step would be an > > SGA. > > > > I agree with Justin. > > The lack of an SGA makes this ineligible for the normal lazy consensus route. > The fact that 1 of the chunks of code you're looking at is licensed > under the EPL is a further blocker. You can't relicense it without > explicit permission from the owner, preferably memorialized as a SGA. > > While I don't think that the IP Clearance process is perfectly rigid, > it is a process and this one is missing some significant parts of that > process. > > --David > > - > 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
Re: [RESULT] [IP CLEARANCE] Maven Wrapper
I do not have answers to those questions, which seems like good ones. I just wanted to break the loop, which I think I might have ;-) On Mon, Feb 3, 2020 at 5:13 PM David Nalley wrote: > > My sense from reading this thread is that it was a 'work-for-hire' and > that the contributors are not owners. Otherwise, why have they been > bothering to talk to Walmart Labs? Why is a company (as opposed to > project or indivudal(s)) listed as the copyright holder in source > code? > > The copyright headers identify Takari Inc as the copyright > holder/owner, which from this thread seems to have been acquired by > Walmart Labs? > > --David > > On Mon, Feb 3, 2020 at 11:01 PM Brian Fox wrote: > > > > I think what Robert is highlighting was that collectively, the > > contributors are still owners and have granted permission to use > > another license. > > > > On Mon, Feb 3, 2020 at 4:59 PM David Nalley wrote: > > > > > > On Mon, Feb 3, 2020 at 9:27 PM Justin Mclean > > > wrote: > > > > > > > > HI, > > > > > > > > I agree with what John wrote, part of the code is EPL which is not > > > > compatible with the ALv2, you need the owner permission to change the > > > > license on that.. > > > > > > > > My understanding of "Let me try to get in contact with Walmart Labs to > > > > get an SGA for the Takari Maven Wrapper.” was that the next step would > > > > be an SGA. > > > > > > > > > > I agree with Justin. > > > > > > The lack of an SGA makes this ineligible for the normal lazy consensus > > > route. > > > The fact that 1 of the chunks of code you're looking at is licensed > > > under the EPL is a further blocker. You can't relicense it without > > > explicit permission from the owner, preferably memorialized as a SGA. > > > > > > While I don't think that the IP Clearance process is perfectly rigid, > > > it is a process and this one is missing some significant parts of that > > > process. > > > > > > --David > > > > > > - > > > 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 > > > > - > 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
Re: [DISCUSS] Distribution guidelines for other platforms
I independently noticed and added [1] so that's covered. On Mon, Jun 29, 2020 at 12:06 PM Joey Frazee wrote: > > Justin this is great and I find myself searching mailing lists and INFRA and > LEGAL JIRAs for past guidance like this. > > A few nit-y suggestions: > > - I think it’d be helpful to link out to the Nexus info [1]. > - Maybe add a comment about who/how to get the ability to publish under the > Docker Hub account. > - And, encouragement to follow the same signing and checksumming practice as > for releases. > > What do you think? > > -joey > > 1. https://infra.apache.org/publishing-maven-artifacts.html > > On Jun 28, 2020, 3:00 AM -0500, Justin Mclean , wrote: > > Hi, > > The name on Pipy could be https://pypi.org/project/apache- to > keep consistent with other platforms. > > The name on NPM has the same issue. > > > As long as it clear it’s an Apache project (for releases made by the PPMC) > then any similar variations is fine. > > Thanks, > Justin > - > 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
