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 @
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.
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 that
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 statements
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
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
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
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
-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 aversion or repugnance'.
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 convole
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 repugnance'.
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
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 short
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 around
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.
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
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
Noel J. Bergman wrote:
snip excelent arguemetns for making a smart repositories./
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
Why not just protocol://repository-path/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
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
Noel J. Bergman wrote:
Why not just protocol://repository-path/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
24 matches
Mail list logo
