I just ran into this and found that might be worth injecting into the
jar repositories discussions.
http://nbbuild.netbeans.org/scrambler.html
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
Pluralitas non est ponenda sine necessitate [William of Ockham]
Stefano Mazzocchi <[EMAIL PROTECTED]> wrote on 28/02/2003 11:06:51 AM:
> I just ran into this and found that might be worth injecting into the
> jar repositories discussions.
>
> http://nbbuild.netbeans.org/scrambler.html
That one is listed up @
http://nagoya.apache.org/wiki/apachewiki.cg
> I just ran into this and found that might be worth injecting into the
> jar repositories discussions.
> http://nbbuild.netbeans.org/scrambler.html
Yes. That is what I was referring to when I mentioned click-through
licenses on netbeans.org, and Costin seems to be aware of it as well.
FWIW,
Maven has been following up with Sun on a click-through approach to
allowing BCL code to be distributed. Geir is the man on the ground for us.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
"Noel J. Bergma
On Thu, 2003-02-27 at 20:16, [EMAIL PROTECTED] wrote:
> FWIW,
>
> Maven has been following up with Sun on a click-through approach to
> allowing BCL code to be distributed. Geir is the man on the ground for us.
> --
Two things to note:
1) Brian over on the maven-dev list has functioning code th
Dion,
> > The reason for this challenge is simple: to
> > demonstrate the the antipathy towards other
> > ASF efforts is damaging not only to the ASF,
> > but to Maven itself.
> 'antipathy' == 'A strong feeling of aversion or repugnance'.
However you want to label it, Jason's harshly phrased sta
Just for reference - I'm somewhat surprised at the flack handed out to
Jason. He and the other Maven committers are doing an out-and-out
brilliant job of bringing together the next generation. My feeling is
that these guys are being squeezed unnecessarily - but don't ask me
why because I don't kn
Leo Simons wrote:
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the infrastructure
team I'm doing lots of CCing, just once)
FYI, the JPackage project where I'm also involved, as set up
a Java RPM centric distribu
Henri Gomez wrote, On 28/02/2003 15.08:
Leo Simons wrote:
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the
infrastructure team I'm doing lots of CCing, just once)
FYI, the JPackage project where I'm also involv
Henri Gomez wrote:
FYI, the JPackage project where I'm also involved, as set up
a Java RPM centric distribution where you could find many
(still not all) apache's java projects.
http://.jpackage.org/
Hi, Henry. I'm using them and they are awful to simplify maintenance of
linux rpm based machin
Hi,
For those of you that don't know I'm behind the effort for a monthly(ish)
newsletter from the folks at jakarta. The original aim was to help
developers stay informed of whats going on in the rest of Jakarta without
them having to monitor every list, each subproject would send in tidbits
of th
-"Noel J. Bergman" <[EMAIL PROTECTED]> wrote: -
> Dion,
> > > The reason for this challenge is simple: to
> > > demonstrate the the antipathy towards other
> > > ASF efforts is damaging not only to the ASF,
> > > but to Maven itself.
> > 'antipathy' == 'A strong feeling of aversio
Are you arguing that the ASF should stop striving to keep licenses
compatible?
No. Where did you get that idea?
Probably entirely from my own paranoia that people would rather write
code than deliver easy to adopt software. My apologies. - ben
---
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
> Seeing the interest it has raised, I tend to think think it's time to
> get the act together and start working on it. I'd like to propose this
> for incubation ASAP, so to not loose momentum.
> ...
>
> Codebases or part of codebases that could co
On Fri, 2003-02-28 at 02:04, Noel J. Bergman wrote:
> Dion,
>
> > > The reason for this challenge is simple: to
> > > demonstrate the the antipathy towards other
> > > ASF efforts is damaging not only to the ASF,
> > > but to Maven itself.
>
> > 'antipathy' == 'A strong feeling of aversion or rep
Costin Manolache wrote:
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
Seeing the interest it has raised, I tend to think think it's time to
get the act together and start working on it. I'd like to propose this
for incubation ASAP, so to not loose momentum.
...
Codebases or part of codebases
> Representing Jason as all Maven developers is a leap
> beyond that I can't fathom.
As I said, I would expect that his comments weren't reflecting Maven's as a
group, and I know that they don't reflect yours.
> It seems you are confusing your view of Jason, which you admit is limited
> to a shor
Jason,
Did anyone question that you've contributed an immeasurable amount of good?
I didn't.
What happened was that you responded negatively to an aside about why not to
put Ant and Maven under a single PMC. You talked about about not being
forced to collaborate, and pulled Gump, centipede, the
On Fri, 28 Feb 2003, Noel J. Bergman wrote:
> > Collaboration does happen, now. It's not a future waiting to happen.
> > Is there something that's not happening that specifically needs to be
> > looked at?
>
> That's the irony. As far as I can see, most of the build processes could
> converge a
Costin Manolache wrote:
I am worried that Maven will use agressive propaganda and the ASF brand
to compete against Ant. All I've seen so far suggest that.
All your projects are belong to us.
- Kasper
-
To unsubscribe, e-mail: [EM
All your projects are belong to us.
:-D
Excelent.
This thread needed a good joke
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
Nick,
As long as you want to start with first principles ...
> >If we have a layout and metadata we agree on - any tool could work.
> >If it is an ant task or a perl program or we just rsync - it doesn't
> >matter.
> A somewhat standard layout is the important part.
> project/[subproject]/versi
Noel J. Bergman wrote:
Nick,
As long as you want to start with first principles ...
project/[subproject]/version/(jar|zip|gz|docs|liscenses)
is very good.
How much should be encoded in a URI, and how much in data associated with
the URI? You seem to be trying to encode all of the data into
Nick,
My apologies for reformatting your reply, but I thought that it made sense
to rename the thread, and still keep the context intact.
How did you perceive my strawman to be incompatible with a filesystem only
approach? If the URI for an addressable entity results in an XML file, for
example,
Noel J. Bergman wrote:
The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart s
This is a top of my head list of requirements for the Apache Jar
Repository (AJR)
* AJR shall
o only host artifacts approved by a PMC
o be accessible to the public via http
o be mirrorable.
* AJR should
o provide metadata about a project,
Noel J. Bergman wrote:
The point of
agreement is the format of the URI and the schema for the descriptor files,
and everything is mapped from there.
Then I propose the URI be
/projectname/[subproject]/[version]/artifactname
Which would allow a simple filesytem backend or an advanced smart s
Nick Chalko wrote:
This is a top of my head list of requirements for the Apache Jar
Repository (AJR)
* AJR shall
o only host artifacts approved by a PMC
o be accessible to the public via http
o be mirrorable.
allow browsing and downloding of artifacts by humans
Why not just ":///artifact-name", where artifact
name is as qualified as necessary, and is permanent? The project name,
sub-project relationships, versioning, etc., could all be handled by the
descriptor contents.
For the smart repository approach, if you want to add additional contraints
use a R
I think in general ./ or ./index.html should return a human readable
form and ./index.xml should give machine readable form of the following
* /
o list of projects in the repository
* /project
o list of subprojects
o list of versions available if there is no su
Noel J. Bergman wrote:
Why not just ":///artifact-name", where artifact
name is as qualified as necessary, and is permanent? The project name,
sub-project relationships, versioning, etc., could all be handled by the
descriptor contents.
So http:repo.apache.org/ant
would return a discriptor such a
31 matches
Mail list logo