You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/08/21 17:53:07 UTC
http://jira.codehaus.org/browse/MNG-3151
I'm not sure this is something we want to encourage before the
patches are applied. Keeping the sources and javadoc JARs together
seems like a good thing to do. The sources and javadocs located in
different locations doesn't seem to make much sense to me and there's
no real explanation within the report.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stefano Bagnara <ap...@bago.org>.
Jason van Zyl ha scritto:
>
> If you are using the IDE integration how is it going to know where to
> find the sources and javadocs for debugging. That's one simple case.
> By adding a tweak to make the deployment diverge from the standard you
> potentially ruin the integration with other tooling. Separating the
> deployment makes IDE integration not work, makes getting sources or
> Javadocs not work for the command-line IDE integration. The
> assumption, at a fundamental level, in Maven is that the secondary
> artifacts are always deployed with the primary artifact.
You're of course much more entitled in judging what is the worse assumption.
Btw, your answer was what I was looking for: now it is more clear why
you are against the patch (previously you gave no motivation excluding
"a good thing to do" and "doesn't seem to make much sense" :-) ).
PS: If you add this in maven core then the IDE integrations might take
care of it once. Otherwise maybe plugin author will find their own way
to hack around this and IDE integrations will have no choice but fail.
Of course If we cannot identify any reason to separate them, then there
is no problem.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Aug 07, at 9:43 AM 21 Aug 07, Stefano Bagnara wrote:
> Jason van Zyl ha scritto:
>> I'm not sure this is something we want to encourage before the
>> patches
>> are applied. Keeping the sources and javadoc JARs together seems like
>> a good thing to do. The sources and javadocs located in different
>> locations doesn't seem to make much sense to me and there's no real
>> explanation within the report.
>>
> I see there are 4 open bugs depending on this feature request:
>
> http://jira.codehaus.org/browse/MASSEMBLY-231
> http://jira.codehaus.org/browse/MSOURCES-20
> http://jira.codehaus.org/browse/MJAVADOC-142
> http://jira.codehaus.org/browse/MDEPLOY-61
>
> This does not seem only related to javadocs and source jars. What kind
> of "real explanation" do you expect for a similar feature request?
>
The purpose of separating and what real value there is in separating
them.
> IMHO adding a feature does not mean "encouraging" its usage: it simply
> means make it possible (you know there are always corner cases when
> using maven).
If it's possible people will do it because they can, not necessarily
because it makes any sense. I don't like adding features just because
someone wants the feature. So again, what real value is there in
separating the sources, javadocs or any other secondary artifact from
the primary artifact.
>
> What problems do you see in applying this patch apart the
> encouragement
> issue?
If you are using the IDE integration how is it going to know where to
find the sources and javadocs for debugging. That's one simple case.
By adding a tweak to make the deployment diverge from the standard
you potentially ruin the integration with other tooling. Separating
the deployment makes IDE integration not work, makes getting sources
or Javadocs not work for the command-line IDE integration. The
assumption, at a fundamental level, in Maven is that the secondary
artifacts are always deployed with the primary artifact.
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 31/08/2007, at 7:27 AM, Wayne Fay wrote:
>> If this is the case, how will we file it in JIRA? Do we need a "needs
>> votes" version? Or just back to 2.0.x with a comment in there?
>
> I suppose a "needs votes" version is as valid as any other approach.
> Then assuming it gets "enough" votes and comments, we can worry about
> implementing it.
Thanks Wayne. It makes sense, so I'm happy to go with this.
>
>> How many users would you want to request it before thinking the use
>> case is valid?
>
> Its a valid question, and I won't pretend to have an answer. I don't
> like magic numbers. But I do feel like this is an important issue with
> far-reaching implications and we should expect/require more than a
> normal level of discussion etc.
Yep, that makes the most sense. It could almost be "more than one" -
if we build up use cases we can continue to eval whether there are
other better solutions or whether, in fact, separation makes the most
sense. You're right that there'd be no magic number. I'm sure we can
make some constructive progress based on concrete examples.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Wayne Fay wrote:
> input on this issue. Its easy enough to do with SurveyMonkey, assuming
> we can find someone to write it using neutral language to avoid
> unintended bias.
Spoilsport!
How are people supposed to b*tch and moan about the biased survey
results if you go and get somebody to write up the survey in neutral
language.
Next you'll be trying to ban flamewars ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Wayne Fay <wa...@gmail.com>.
> If this is the case, how will we file it in JIRA? Do we need a "needs
> votes" version? Or just back to 2.0.x with a comment in there?
I suppose a "needs votes" version is as valid as any other approach.
Then assuming it gets "enough" votes and comments, we can worry about
implementing it.
> How many users would you want to request it before thinking the use
> case is valid?
Its a valid question, and I won't pretend to have an answer. I don't
like magic numbers. But I do feel like this is an important issue with
far-reaching implications and we should expect/require more than a
normal level of discussion etc.
I'm fine continuing the discussion here, asking for input from users@,
or even posting a survey on maven.apache.org to get other people's
input on this issue. Its easy enough to do with SurveyMonkey, assuming
we can find someone to write it using neutral language to avoid
unintended bias.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Aug 07, at 10:40 PM 29 Aug 07, Brett Porter wrote:
>
>
> It's possible with Archiva too, but James has given what I feel is
> a perfectly valid reason why that's a pain, and it ends up in the
> same logical result (a repository that has everything, but appears
> not to).
>
That's not the issue, how it appears logically is not important. The
issue is the physical deployment to separate repositories. With
mod_rewrite, or one of the repository tools, but what you end up is a
disjunct amongst the primary and secondary artifacts. That's the issue.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 30/08/2007, at 3:32 PM, Jason van Zyl wrote:
>
> On 29 Aug 07, at 10:06 PM 29 Aug 07, Wayne Fay wrote:
>
>>>> Does anyone else think this is a terrible idea? If we allow this
>>>> then there is no going back.
>>>
>>> Yah, I'd love to hear it if anyone can pick holes in it, as I don't
>>> want to steer down any bad tracks repository wise either.
>>
>> I'm not a huge fan simply because I like the simplicity of
>> "everything
>> in one place". But I'm having trouble coming up with a really huge
>> problem with it, other than the way it smells to me in general. I can
>> understand both perspectives on the issue.
>>
>> I have some small concerns around making this far-reaching decision
>> based on the needs/request of what seems to be a single "customer".
>> I'd prefer to let this be an open issue for a while and revisit it in
>> 6mos, allow other customers to make their own possibly similar
>> comments/demands, and see how it feels/smells in early 2008.
>>
>
> That's probably wise as I feel this would have nothing but
> detrimental effects. The squeaky wheel doesn't get multiple
> repositories in my opinion.
If this is the case, how will we file it in JIRA? Do we need a "needs
votes" version? Or just back to 2.0.x with a comment in there?
How many users would you want to request it before thinking the use
case is valid?
> As it is possible with Proximity to solve this problem anyway.
It's possible with Archiva too, but James has given what I feel is a
perfectly valid reason why that's a pain, and it ends up in the same
logical result (a repository that has everything, but appears not to).
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Aug 07, at 10:06 PM 29 Aug 07, Wayne Fay wrote:
>>> Does anyone else think this is a terrible idea? If we allow this
>>> then there is no going back.
>>
>> Yah, I'd love to hear it if anyone can pick holes in it, as I don't
>> want to steer down any bad tracks repository wise either.
>
> I'm not a huge fan simply because I like the simplicity of "everything
> in one place". But I'm having trouble coming up with a really huge
> problem with it, other than the way it smells to me in general. I can
> understand both perspectives on the issue.
>
> I have some small concerns around making this far-reaching decision
> based on the needs/request of what seems to be a single "customer".
> I'd prefer to let this be an open issue for a while and revisit it in
> 6mos, allow other customers to make their own possibly similar
> comments/demands, and see how it feels/smells in early 2008.
>
That's probably wise as I feel this would have nothing but
detrimental effects. The squeaky wheel doesn't get multiple
repositories in my opinion. As it is possible with Proximity to solve
this problem anyway.
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Wayne Fay <wa...@gmail.com>.
> > Does anyone else think this is a terrible idea? If we allow this
> > then there is no going back.
>
> Yah, I'd love to hear it if anyone can pick holes in it, as I don't
> want to steer down any bad tracks repository wise either.
I'm not a huge fan simply because I like the simplicity of "everything
in one place". But I'm having trouble coming up with a really huge
problem with it, other than the way it smells to me in general. I can
understand both perspectives on the issue.
I have some small concerns around making this far-reaching decision
based on the needs/request of what seems to be a single "customer".
I'd prefer to let this be an open issue for a while and revisit it in
6mos, allow other customers to make their own possibly similar
comments/demands, and see how it feels/smells in early 2008.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 30/08/2007, at 2:56 AM, Jason van Zyl wrote:
>
> On 29 Aug 07, at 8:20 AM 29 Aug 07, Brett Porter wrote:
>
>>
>> On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
>>
>>
>> Like with any other artifact (including if versions are split
>> across multiple repositories), it searches them all in sequence if
>> they aren't found in one.
>>
>
> This seems like a good practice to you?
>
> Primary in one repository and secondary artifacts in another?
The use case seems valid to me, yes.
> Metadata misalignment, mis-configuration, who know what other
> problems lurk and just the general practice of doing this.
When I ran the test case, there's only one set of metadata for a
given version (it sits in the main repository) - which makes sense to
me. (But even if they were updated on each, they'd all merge just fine).
>
> Does anyone else think this is a terrible idea? If we allow this
> then there is no going back.
Yah, I'd love to hear it if anyone can pick holes in it, as I don't
want to steer down any bad tracks repository wise either. So, if
anyone has any specific examples of where this would be
undesirable... shoot :)
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 29 Aug 07, at 8:20 AM 29 Aug 07, Brett Porter wrote:
>
> On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
>
>
> Like with any other artifact (including if versions are split
> across multiple repositories), it searches them all in sequence if
> they aren't found in one.
>
This seems like a good practice to you?
Primary in one repository and secondary artifacts in another?
Metadata misalignment, mis-configuration, who know what other
problems lurk and just the general practice of doing this.
Does anyone else think this is a terrible idea? If we allow this then
there is no going back.
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 30/08/2007, at 1:11 AM, Jason van Zyl wrote:
>
> On 28 Aug 07, at 10:08 PM 28 Aug 07, Brett Porter wrote:
>
>> Where are we with this?
>>
>> The thread went a bit off the rails for some other stuff, and the
>> only other suggestion I saw was:
>>
>>> On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
>>>> But the case that Atlassian wants solved would be very simple
>>>> with something like Proximity even today. One simple access
>>>> controller that blocked the source jars for particular users and
>>>> you're set.
>>
>> But that conflicted with this:
>>
>> On 22/08/2007, at 3:09 PM, James William Dumay wrote:
>>
>>> Customers currently download the sources from the website, not
>>> checking
>>> them out from the repository. Having a password protected repository
>>> would mean we would have to add more admin overhead to the Developer
>>> Network team.
>>
>> Given that we're now talking about setting up something that is
>> logically equivalent (by blocking, or not promoting, some
>> artifacts to one repository but keeping them available from
>> another internal one), I think it makes sense to go with a
>> solution that makes it as easy as possible for the user, so I'm
>> happy with the patch.
>>
>> I ran up a quick test project, and if the artifacts are split in
>> this way, mvn idea:idea -DdownloadSources=true -
>> DdownloadJavadocs=true behaves as expected.
>>
>
> How if they are in different repositories?
>
>> Are there other objections?
>>
>
> -1
>
> How can this possibly work in a coherent manner? How does the IDEA
> and Eclipse know where to go if they are split up?
Like with any other artifact (including if versions are split across
multiple repositories), it searches them all in sequence if they
aren't found in one.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Aug 07, at 10:08 PM 28 Aug 07, Brett Porter wrote:
> Where are we with this?
>
> The thread went a bit off the rails for some other stuff, and the
> only other suggestion I saw was:
>
>> On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
>>> But the case that Atlassian wants solved would be very simple
>>> with something like Proximity even today. One simple access
>>> controller that blocked the source jars for particular users and
>>> you're set.
>
> But that conflicted with this:
>
> On 22/08/2007, at 3:09 PM, James William Dumay wrote:
>
>> Customers currently download the sources from the website, not
>> checking
>> them out from the repository. Having a password protected repository
>> would mean we would have to add more admin overhead to the Developer
>> Network team.
>
> Given that we're now talking about setting up something that is
> logically equivalent (by blocking, or not promoting, some artifacts
> to one repository but keeping them available from another internal
> one), I think it makes sense to go with a solution that makes it as
> easy as possible for the user, so I'm happy with the patch.
>
> I ran up a quick test project, and if the artifacts are split in
> this way, mvn idea:idea -DdownloadSources=true -
> DdownloadJavadocs=true behaves as expected.
>
How if they are in different repositories?
> Are there other objections?
>
-1
How can this possibly work in a coherent manner? How does the IDEA
and Eclipse know where to go if they are split up?
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
Where are we with this?
The thread went a bit off the rails for some other stuff, and the
only other suggestion I saw was:
> On 23/08/2007, at 3:32 AM, Jason van Zyl wrote:
>> But the case that Atlassian wants solved would be very simple with
>> something like Proximity even today. One simple access controller
>> that blocked the source jars for particular users and you're set.
But that conflicted with this:
On 22/08/2007, at 3:09 PM, James William Dumay wrote:
> Customers currently download the sources from the website, not
> checking
> them out from the repository. Having a password protected repository
> would mean we would have to add more admin overhead to the Developer
> Network team.
Given that we're now talking about setting up something that is
logically equivalent (by blocking, or not promoting, some artifacts
to one repository but keeping them available from another internal
one), I think it makes sense to go with a solution that makes it as
easy as possible for the user, so I'm happy with the patch.
I ran up a quick test project, and if the artifacts are split in this
way, mvn idea:idea -DdownloadSources=true -DdownloadJavadocs=true
behaves as expected.
Are there other objections?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Gregory Kick <gk...@gmail.com>.
On 8/22/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote:
>
> >
> >>
> >> It does if you use a shared file system, many people actually use
> >> this. And simple Window file perms work here to protect it.
> >
> > How do you deal with concurrent writes?
> >
>
> There's nothing you can do here with Wagon in general right now. This
> is not local to the file wagon.
That was my point. Without some sort of server interception, you
can't solve that problem, so file-based remote repositories on shared
drives are probably a bad idea...
>
> >>
> >>> , all of them require some sort of
> >>> server somewhere. Granted, a lot of people have sshd or httpd or
> >>> ftpd
> >>> running so it's not an extra process, but there's still _something_
> >>> running on the other end no matter what. Also, I'd be pretty
> >>> surprised to find that a significant portion of the people running a
> >>> remote repository weren't running a servlet container already as
> >>> well.
> >>> Plus, there's always jetty or winstone if you want a quick install.
> >>>
> >>
> >> No argument that in the very near future I don't think anyone will
> >> use a Maven repository without a front-end application. Web servers
> >> are just too stupid, security is annoying, you have no transactional
> >> behaviour, and you have to expose the internal structure.
> >>
> >>> I'm also pretty sure that there's going to be some question of
> >>> backwards compatibility. Well, seeing that I'm suggesting a RESTful
> >>> service, it could have the exact same structure as what's being used
> >>> now. I'm not entirely sure I'd recommend that, but it _could_.
> >>> If it
> >>> didn't you could always just add a new layout.
> >>>
> >>
> >> The repository managers will have an API, and can be exposed via REST
> >> which will end up being one of the favored modes of operation. But I
> >> see applications interacting directly with client side APIs to get
> >> things done. Like Maven deployments, releases, searching, what
> >> have you.
> >
> > This seems like it'd end up being problematic for a couple of reasons.
> > The first is that when you say that it _can_ be exposed via REST this
> > implies too much flexibility in what the resource URIs look like.
>
> There's no reason that there can't be a standard URI, but honestly I
> don't see the REST API being the most used form of access.
You expect a transport other than http to be most common? Which?
>
> > To
> > provide a decent user experience from both the application and the
> > browser, there has to be some standardization for the rest api.
>
> Not disagreeing with you.
>
> > Not
> > that the current layout doesn't have a standard interface, but the
> > format of the results for directory listings and the URIs for
> > additional functionality would end up being all over the place.
>
> What is used to logically represent an artifact via a URI can be
> decoupled from where it resides physically. Looking directly at the
> web server is not necessarily representative of what the REST API
> would provide.
I'm not sure that I'm on the same page with what you mean by
"physically." I think physical in terms of mean where it is on disk,
which even with just raw apache can have little/nothing to do with
what uri it's served from. So, if you were to use additional uris to
represent a given resource, the typical
http://.../group/artifact/version/blah.jar would still be the
cannonical uri if it's available as well. For that reason, I
envisioned a REST api that was a superset of the GET requests that the
lightweight http wagon uses now.
>
> >
> > The other issue is that, from a developer perspective, I'd rather
> > there not be a standard java api. If the job of a repository is to
> > serve artifacts, that should be the only contract to which I'm bound
> > (especially if the maven code is still compiling with 1.4).
>
> It's not the only responsibility of the repository, and I disagree
> that people won't want to use an API. But again, there is no reason
> that we can't have a standard REST API built upon the standard API
> which would satisfy your primary concern. For pulling artifacts 9/10
> people will most likely use HTTP, but we have many people using SCP
> and FTP for whatever their reasons.
>
> > Unless
> > there's a really compelling reason to support other transports,
>
> Existing users that are not pulling with HTTP.
Yeah, and that's definitely a concern, but I wonder whether that's a
result of infrastructure requirements or the fact that you currently
have to jump through so many hoops to push with http/webdav.
>
> > any
> > additional api just adds another layer. Of course, the maven-built RI
> > could add whatever api it wants, but I can't think of a scenario in
> > which you'd need to support its invocation from anything other than
> > the transport.
> >
>
> A repository manager will ultimately be responsible for more then
> pulling artifacts. For pulling and the 9/10 people using HTTP, and
> for those who simply want access to the repository we can provide
> this common REST API and no one will be the wiser. But for
> deployments, releases, searching, retrieval of incremental indices,
> retrieval of stats a standard API will be of greater use. It's what
> we would use directly from Maven and any tooling would be more
> interested in using this API.
I guess my point was more that given full push and pull support over
http, scp and ftp probably wouldn't have had much use. So, if we're
finally to the point where it makes sense for repositories to have a
server-side presence we can move towards a unified transport that
supports push, pull and algorithm execution. REST makes sense to me
because you can see it in a browser and still support _all_ of the
operations on repository. Otherwise, how do you get stats via SCP or
FTP? How do you search without making the client do all of the work?
>From the sounds of it, you're separating the duties of the repository
from the repository manager, but with issues like transactional
deployment, you really have to have that be a function of the
repository, otherwise you have to enforce that all deployment go
through the manager. (right?) If that's the case then you're
exposing push and pull via some transport and your other ops (e.g.
stats) via another.
I guess the whole point is that the current system is all over the
place and has some issues. Given all that we know now, and all that
we know that people want to do with repositories, is it
feasible/reasonable/desired to support this whole multi-transport
abstraction for repositories with a server-side presence?
>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Gregory Kick
http://kickstyle.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Aug 07, at 11:23 AM 22 Aug 07, Gregory Kick wrote:
>
>>
>> It does if you use a shared file system, many people actually use
>> this. And simple Window file perms work here to protect it.
>
> How do you deal with concurrent writes?
>
There's nothing you can do here with Wagon in general right now. This
is not local to the file wagon.
>>
>>> , all of them require some sort of
>>> server somewhere. Granted, a lot of people have sshd or httpd or
>>> ftpd
>>> running so it's not an extra process, but there's still _something_
>>> running on the other end no matter what. Also, I'd be pretty
>>> surprised to find that a significant portion of the people running a
>>> remote repository weren't running a servlet container already as
>>> well.
>>> Plus, there's always jetty or winstone if you want a quick install.
>>>
>>
>> No argument that in the very near future I don't think anyone will
>> use a Maven repository without a front-end application. Web servers
>> are just too stupid, security is annoying, you have no transactional
>> behaviour, and you have to expose the internal structure.
>>
>>> I'm also pretty sure that there's going to be some question of
>>> backwards compatibility. Well, seeing that I'm suggesting a RESTful
>>> service, it could have the exact same structure as what's being used
>>> now. I'm not entirely sure I'd recommend that, but it _could_.
>>> If it
>>> didn't you could always just add a new layout.
>>>
>>
>> The repository managers will have an API, and can be exposed via REST
>> which will end up being one of the favored modes of operation. But I
>> see applications interacting directly with client side APIs to get
>> things done. Like Maven deployments, releases, searching, what
>> have you.
>
> This seems like it'd end up being problematic for a couple of reasons.
> The first is that when you say that it _can_ be exposed via REST this
> implies too much flexibility in what the resource URIs look like.
There's no reason that there can't be a standard URI, but honestly I
don't see the REST API being the most used form of access.
> To
> provide a decent user experience from both the application and the
> browser, there has to be some standardization for the rest api.
Not disagreeing with you.
> Not
> that the current layout doesn't have a standard interface, but the
> format of the results for directory listings and the URIs for
> additional functionality would end up being all over the place.
What is used to logically represent an artifact via a URI can be
decoupled from where it resides physically. Looking directly at the
web server is not necessarily representative of what the REST API
would provide.
>
> The other issue is that, from a developer perspective, I'd rather
> there not be a standard java api. If the job of a repository is to
> serve artifacts, that should be the only contract to which I'm bound
> (especially if the maven code is still compiling with 1.4).
It's not the only responsibility of the repository, and I disagree
that people won't want to use an API. But again, there is no reason
that we can't have a standard REST API built upon the standard API
which would satisfy your primary concern. For pulling artifacts 9/10
people will most likely use HTTP, but we have many people using SCP
and FTP for whatever their reasons.
> Unless
> there's a really compelling reason to support other transports,
Existing users that are not pulling with HTTP.
> any
> additional api just adds another layer. Of course, the maven-built RI
> could add whatever api it wants, but I can't think of a scenario in
> which you'd need to support its invocation from anything other than
> the transport.
>
A repository manager will ultimately be responsible for more then
pulling artifacts. For pulling and the 9/10 people using HTTP, and
for those who simply want access to the repository we can provide
this common REST API and no one will be the wiser. But for
deployments, releases, searching, retrieval of incremental indices,
retrieval of stats a standard API will be of greater use. It's what
we would use directly from Maven and any tooling would be more
interested in using this API.
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 29/08/2007, at 6:14 PM, Nigel Magnay wrote:
> Which is great - it just felt like there was some disagreement between
> whether it's actually a problem to be fixed :- "let's fix the local
> repository" vs "Yes, I'm just saying separate processes should be
> using
> separate local repositories." which I didn't understand as I
> couldn't see
> how a locally built artifact would then be able to be accessed by
> downstream
> builds.
>
> Is there a JIRA covering this one (I guess there's probably
> several ;-) ) -
> MNG-3151 seems to me to be a slightly different thing from what
> we're now
> talking about.
yeah, the thread kind of diverged from the original intent. I'm not
sure if there's a JIRA yet - but there should be. I've added it to my
queue to write up as a proposal and add to JIRA if not already there.
If you want to search/create and then watch and let me know I'd be
happy to use that one.
- Brett
>
>
> On 29/08/2007, Brett Porter <br...@apache.org> wrote:
>>
>> I already responded to this here: http://www.nabble.com/Re%3A-local-
>> repositories-%28was%3A-http%3A--jira.codehaus.org-browse-MNG-3151%29-
>> p12286344s177.html
>>
>> Cheers,
>> Brett
>>
>> On 29/08/2007, at 4:49 PM, Nigel Magnay wrote:
>>
>>>>
>>>> If you are knowingly doing this then I would say different settings
>>>> via a build plan to prevent corruption or the CI mechanism
>>>> serializes
>>>> the builds.
>>>>
>>>
>>> How can one do this and still make use of all 8 cores to build on a
>>> desktop machine (or all 16 on our CI server)? m2 builds could run
>>> really parallel, but they frequently break when they do
>>> (particularly
>>> when one buildl downloads a plugin, and another one uses it half-way
>>> through, getting wrong metadata).
>>>
>>> Is there a way of serializing access to the local repository?
>>>
>>> This seems a really important feature given the way computers are
>>> rapidly adding cores. m2 has the intelligence to know what things
>>> can
>>> be parallelized because of its smart dependency mechanism, but it
>>> falls down because of the dumb local repo into an antlike serial
>>> process.
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Nigel Magnay <ni...@gmail.com>.
Which is great - it just felt like there was some disagreement between
whether it's actually a problem to be fixed :- "let's fix the local
repository" vs "Yes, I'm just saying separate processes should be using
separate local repositories." which I didn't understand as I couldn't see
how a locally built artifact would then be able to be accessed by downstream
builds.
Is there a JIRA covering this one (I guess there's probably several ;-) ) -
MNG-3151 seems to me to be a slightly different thing from what we're now
talking about.
On 29/08/2007, Brett Porter <br...@apache.org> wrote:
>
> I already responded to this here: http://www.nabble.com/Re%3A-local-
> repositories-%28was%3A-http%3A--jira.codehaus.org-browse-MNG-3151%29-
> p12286344s177.html
>
> Cheers,
> Brett
>
> On 29/08/2007, at 4:49 PM, Nigel Magnay wrote:
>
> >>
> >> If you are knowingly doing this then I would say different settings
> >> via a build plan to prevent corruption or the CI mechanism serializes
> >> the builds.
> >>
> >
> > How can one do this and still make use of all 8 cores to build on a
> > desktop machine (or all 16 on our CI server)? m2 builds could run
> > really parallel, but they frequently break when they do (particularly
> > when one buildl downloads a plugin, and another one uses it half-way
> > through, getting wrong metadata).
> >
> > Is there a way of serializing access to the local repository?
> >
> > This seems a really important feature given the way computers are
> > rapidly adding cores. m2 has the intelligence to know what things can
> > be parallelized because of its smart dependency mechanism, but it
> > falls down because of the dumb local repo into an antlike serial
> > process.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
I already responded to this here: http://www.nabble.com/Re%3A-local-
repositories-%28was%3A-http%3A--jira.codehaus.org-browse-MNG-3151%29-
p12286344s177.html
Cheers,
Brett
On 29/08/2007, at 4:49 PM, Nigel Magnay wrote:
>>
>> If you are knowingly doing this then I would say different settings
>> via a build plan to prevent corruption or the CI mechanism serializes
>> the builds.
>>
>
> How can one do this and still make use of all 8 cores to build on a
> desktop machine (or all 16 on our CI server)? m2 builds could run
> really parallel, but they frequently break when they do (particularly
> when one buildl downloads a plugin, and another one uses it half-way
> through, getting wrong metadata).
>
> Is there a way of serializing access to the local repository?
>
> This seems a really important feature given the way computers are
> rapidly adding cores. m2 has the intelligence to know what things can
> be parallelized because of its smart dependency mechanism, but it
> falls down because of the dumb local repo into an antlike serial
> process.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Nigel Magnay <ni...@gmail.com>.
>
> If you are knowingly doing this then I would say different settings
> via a build plan to prevent corruption or the CI mechanism serializes
> the builds.
>
How can one do this and still make use of all 8 cores to build on a
desktop machine (or all 16 on our CI server)? m2 builds could run
really parallel, but they frequently break when they do (particularly
when one buildl downloads a plugin, and another one uses it half-way
through, getting wrong metadata).
Is there a way of serializing access to the local repository?
This seems a really important feature given the way computers are
rapidly adding cores. m2 has the intelligence to know what things can
be parallelized because of its smart dependency mechanism, but it
falls down because of the dumb local repo into an antlike serial
process.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
File a Jira and I'll see what I can do. I wish the resolver had a nice
interface so I could just ask for a resolved artifact and get the same
behavior as core. I have to keep reimplementing a bunch of stuff.
-----Original Message-----
From: Stephen Connolly [mailto:stephenconnolly@one-dash.com]
Sent: Wednesday, August 22, 2007 4:33 PM
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
Brian E. Fox wrote:
>> One big issue I have is that the maven-dependency-plugin seems to
>>
> ignore
>
>> artifacts produced in the current build execution and only pulls from
>> the local repository... so I have to run "mvn install" all the
time...
>>
>
> Which goal? The unpack, copy yes, but unpack/copy-dependencies will
work
> with package.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
And that would be the two goals we need! unpack and copy!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Brian E. Fox wrote:
>> One big issue I have is that the maven-dependency-plugin seems to
>>
> ignore
>
>> artifacts produced in the current build execution and only pulls from
>> the local repository... so I have to run "mvn install" all the time...
>>
>
> Which goal? The unpack, copy yes, but unpack/copy-dependencies will work
> with package.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
And that would be the two goals we need! unpack and copy!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>One big issue I have is that the maven-dependency-plugin seems to
ignore
>artifacts produced in the current build execution and only pulls from
>the local repository... so I have to run "mvn install" all the time...
Which goal? The unpack, copy yes, but unpack/copy-dependencies will work
with package.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Aug 07, at 12:42 PM 22 Aug 07, Stephen Connolly wrote:
> Jason van Zyl wrote:
>>
>> On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
>>
>>> Gregory Kick wrote:
>>>>
>>>> How do you deal with concurrent writes?
>>>>
>>> That's a nightmare problem with the local repository anyway.
>>>
>>
>> How on earth do you have concurrency problems with a local
>> repository?
>
> That's easy
> ... open two terminals and kick off two builds one after the other
>
> Often the build time is longer than my thinking time... so I have
> two working copies of the project and work on two separate problems
> at the same time...
>
> So I need to do two builds at the same (or near same time)
>
> If only all plugins would understand about artifacts in the package
> scope.
>
> One big issue I have is that the maven-dependency-plugin seems to
> ignore artifacts produced in the current build execution and only
> pulls from the local repository... so I have to run "mvn install"
> all the time...
>
> Easy!
>
Yes, I'm just saying separate processes should be using separate
local repositories.
> -Stephen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Jason van Zyl wrote:
>
> On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
>
>> Gregory Kick wrote:
>>>
>>> How do you deal with concurrent writes?
>>>
>> That's a nightmare problem with the local repository anyway.
>>
>
> How on earth do you have concurrency problems with a local repository?
That's easy
... open two terminals and kick off two builds one after the other
Often the build time is longer than my thinking time... so I have two
working copies of the project and work on two separate problems at the
same time...
So I need to do two builds at the same (or near same time)
If only all plugins would understand about artifacts in the package scope.
One big issue I have is that the maven-dependency-plugin seems to ignore
artifacts produced in the current build execution and only pulls from
the local repository... so I have to run "mvn install" all the time...
Easy!
-Stephen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Jason van Zyl wrote:
>
> On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
>
>> Gregory Kick wrote:
>>>
>>> How do you deal with concurrent writes?
>>>
>> That's a nightmare problem with the local repository anyway.
>>
>
> How on earth do you have concurrency problems with a local repository?
>
>> One team of ours had to scrap switching to Maven as it filled the
>> disk on their shared homes drive... and if they changed the system
>> default to use a common local repository they kept on getting broken
>> builds from two people installing the same (usually snapshot)
>> artifact at the same time!
>>
>
> Using a shared local repository is a very, very, very bad idea.
> Nothing will work if you share one local repository. Again, just a bad
> idea.
Yep... I cringed when I heard this one.
First they crashed the server by having one component built by maven and
"hiding" this in the middle of an ANT build script that everyone does.
Then they have a load of really big dependencies with lots of mini
version updates...
Then they wonder why they run out of disk space.. only to find that it's
the 100 developers all having a 2GB local repository in their home
directory on the shared network server...
Then they say... AHHH we'll just make it a shared local repository...
and they wonder why the other developers think Maven is a pile of cr*p...
Maven is fine... it's just the people who tried to implement it badly!
>
>> It's more of a problem for continuous integration servers that run
>> builds in parallel.
>>
>> However the concurrent write problem is solved for remote
>> repositories, please solve it for local repositories as well!
>
> You're not supposed to be sharing them. You CI system should be
> deploying to a shared remote repository, not writing to a shared local
> repository.
>
Ahhh no... you mis-understand.
CI build system kicks off build of job on machine (that build deploys to
remote repo... but deploy includes install, so installs to local repo
for current user (the user account running the CI service))
CI detects another change and says I have processing capacity to spare,
kicks off another build (or just builds another stream of the same
project) That job also is deploying to remote repo... but deploy
includes install and the local repo is the one for the user account
running the CI service... bang!
Yes _I_ know that the correct way is to configure each and every job to
have it's own local repo... and to clean out that local repo before
every build... and to have caching proxying remote repos so that you can
pull down all the dependencies quickly at the start of each build (as
otherwise the build will take 50 min instead of 5min)
But _I_ am not the person who sets up all the builds! ;-)
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: local repositories
Posted by Brett Porter <br...@apache.org>.
On 23/08/2007, at 3:59 PM, Stephen Connolly wrote:
>> One of the advantages of what you were describing is the ability
>> to not install anything unless the entire build passes - that has
>> some virtues as well, but I consider it a separate feature to
>> fixing the local repository concurrency problems.
> I am torn over which way to run on this question.
I think it's something that would be separately configurable. I don't
think it would be the default. The individual artifacts, once built,
should be useful whether the rest build or not - but it really
depends on your project.
> The only issue is how to push from one layer to the next... don't
> want to end up with another phase between install and deploy (local-
> deploy???) that has the same locking problems!
I wasn't suggesting any pushing here: install goes into separate
local installation repository only, deploy pushes to the remote
repository from there, dependency resolution looks first in the
installation repository, then in the cache (if that's the way it's
defined), and then of course in the remote repository to bring into
the cache. There's no need to migrate things between them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: local repositories
Posted by Stephen Connolly <st...@one-dash.com>.
Brett Porter wrote:
>
> On 23/08/2007, at 7:12 AM, Stephen Connolly wrote:
>
>> Or a better local repository model ;-)
>
> +1. I already started to draft a proposal for the wiki on this, but
> hadn't posted it yet.
>
>>
>> One where there are two local repositories (committed and current
>> build) that get layered together.
>
> What I was actually thinking was the lock operating at the individual
> artifact level, and being a read lock as well as a write lock. The
> installation step itself should be very quick for the artifact and
> it's associated metadata because they are already built, so this is
> not a bad lock to have, and I think it's still necessary to have a
> read lock because there's no way to atomically do the merge you refer
> to later on.
>
> One of the advantages of what you were describing is the ability to
> not install anything unless the entire build passes - that has some
> virtues as well, but I consider it a separate feature to fixing the
> local repository concurrency problems.
I am torn over which way to run on this question.
On CI servers, if we have builds in parallel, and some of those
components have integration tests with non-consistent run times. i.e.
may take 5 min or may take 2 min for the tests to complete, you could
end up with two parallel builds with the second starting 1 min after the
first and mixing the artifacts they use. Of course when all plugins
honour the attached scope resolution for finding artifacts this would
not be an issue!
A simpler fix would be when a Maven process grabs the write lock for an
artifact, it holds the write lock until the process ends.
Thus parallel builds of different projects would not interfere, we
wouldn't need layering (though I'd really like that) and parallel builds
of the same project would be first come holds everyone else until done.
>
>> If you have layering, then you could have a shared local repository
>> as a third layer to save duplication of files.
>
> Yes, this is definitely something I'd like to see. I think that we
> should be separating the cache from the place that developers install
> their own things. There are a number of reasons this is a good idea:
>
> 1) it would simplify a lot of the artifact handling code
> 2) it lets you clean up easily - you likely keep your cache but nuke
> your local builds
> 3) you can create separate local repository workspaces on a single
> machine without needing to redownload all the rest of the cache
> (useful for CI servers)
> 4) you could start to share a cache (though I'd still recommend a
> shared remote repository instead of doing this, it's at least less
> harmful than doing it now)
>
The only issue is how to push from one layer to the next... don't want
to end up with another phase between install and deploy
(local-deploy???) that has the same locking problems!
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: local repositories (was: http://jira.codehaus.org/browse/MNG-3151)
Posted by Brett Porter <br...@apache.org>.
On 23/08/2007, at 7:12 AM, Stephen Connolly wrote:
> Or a better local repository model ;-)
+1. I already started to draft a proposal for the wiki on this, but
hadn't posted it yet.
>
> One where there are two local repositories (committed and current
> build) that get layered together.
What I was actually thinking was the lock operating at the individual
artifact level, and being a read lock as well as a write lock. The
installation step itself should be very quick for the artifact and
it's associated metadata because they are already built, so this is
not a bad lock to have, and I think it's still necessary to have a
read lock because there's no way to atomically do the merge you refer
to later on.
One of the advantages of what you were describing is the ability to
not install anything unless the entire build passes - that has some
virtues as well, but I consider it a separate feature to fixing the
local repository concurrency problems.
> If you have layering, then you could have a shared local repository
> as a third layer to save duplication of files.
Yes, this is definitely something I'd like to see. I think that we
should be separating the cache from the place that developers install
their own things. There are a number of reasons this is a good idea:
1) it would simplify a lot of the artifact handling code
2) it lets you clean up easily - you likely keep your cache but nuke
your local builds
3) you can create separate local repository workspaces on a single
machine without needing to redownload all the rest of the cache
(useful for CI servers)
4) you could start to share a cache (though I'd still recommend a
shared remote repository instead of doing this, it's at least less
harmful than doing it now)
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Jason van Zyl wrote:
>
> On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
>
>>
>>> How on earth do you have concurrency problems with a local repository?
>>
>> Simultaneous builds in a CI system on a multicore machine.
>>
>
> If you are knowingly doing this then I would say different settings
> via a build plan to prevent corruption or the CI mechanism serializes
> the builds.
>
Or a better local repository model ;-)
One where there are two local repositories (committed and current build)
that get layered together.
A simple lock file in ~.m2/ could cause a subsequent build starting
during an overlap period to create it's own local layer
(i.e. current build)
When a build finishes, it waits until it has the lock and then merges
it's local layer with the committed repository. That way all artifiacts
get installed only when the build completes fully and successfully.
If you have layering, then you could have a shared local repository as a
third layer to save duplication of files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
We're currently serializing the builds to avoid this, although I'd like
to parallelize them (3 cores idle). I guess we could isolate each build
to a separate local repo, but that would be a huge amount of disk used
up since most of the builds are also referencing the others, and I have
too many to count in my head ;-)
-----Original Message-----
From: Jason van Zyl [mailto:jason@maven.org]
Sent: Wednesday, August 22, 2007 5:06 PM
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
>
>> How on earth do you have concurrency problems with a local
>> repository?
>
> Simultaneous builds in a CI system on a multicore machine.
>
If you are knowingly doing this then I would say different settings
via a build plan to prevent corruption or the CI mechanism serializes
the builds.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Aug 07, at 1:28 PM 22 Aug 07, Brian E. Fox wrote:
>
>> How on earth do you have concurrency problems with a local
>> repository?
>
> Simultaneous builds in a CI system on a multicore machine.
>
If you are knowingly doing this then I would say different settings
via a build plan to prevent corruption or the CI mechanism serializes
the builds.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>How on earth do you have concurrency problems with a local repository?
Simultaneous builds in a CI system on a multicore machine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Aug 07, at 11:29 AM 22 Aug 07, Stephen Connolly wrote:
> Gregory Kick wrote:
>>
>> How do you deal with concurrent writes?
>>
> That's a nightmare problem with the local repository anyway.
>
How on earth do you have concurrency problems with a local repository?
> One team of ours had to scrap switching to Maven as it filled the
> disk on their shared homes drive... and if they changed the system
> default to use a common local repository they kept on getting
> broken builds from two people installing the same (usually
> snapshot) artifact at the same time!
>
Using a shared local repository is a very, very, very bad idea.
Nothing will work if you share one local repository. Again, just a
bad idea.
> It's more of a problem for continuous integration servers that run
> builds in parallel.
>
> However the concurrent write problem is solved for remote
> repositories, please solve it for local repositories as well!
You're not supposed to be sharing them. You CI system should be
deploying to a shared remote repository, not writing to a shared
local repository.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stephen Connolly <st...@one-dash.com>.
Gregory Kick wrote:
> On 8/22/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
>>
>>
>>> Ok, so I'm coming to the conversation slightly late in the game, but
>>> all of this discussion reminds me of something that's been in the back
>>> of my mind for sometime. With all of the effort put forth in the
>>> various repository managers, front-ends, proxies, mirrors, etc. why
>>> doesn't the whole repository mechanism get a bit more intelligence in
>>> order to solve some of these basic problems?
>>>
>>>
>> Exactly. In short they are. Trying to do anything reasonably
>> intelligent with an unintelligent mechanism like a simple web server
>> is very hard.
>>
>>
>>> AFAIK (and correct me if i'm wrong), http is almost exclusively for
>>> fetching artifacts, so a basic RESTful service could go a long way
>>> towards standardizing some of the things that seem to be pretty
>>> commonly needed. For example:
>>> - authentication/authorization, which is what would solve the problem
>>> discussed in this thread
>>> - basic listing (e.g. what artifacts exist for a given group)
>>> - search (depending on how much logic you really want to give to the
>>> repository)
>>> - standard, machine-readable output. no more scraping apache
>>> directory listings...
>>> - consistent, accurate, real-time metadata
>>> - server-side deployment validation/atomic deploys
>>>
>>> The list could probably go on, but those are just a few quick ideas.
>>> It just seems like there's functionality that I would like to be able
>>> to expect from a repository, but don't get because it's not really
>>> anything more than a big directory. Then, all of the more
>>> sophisticated repository management tools can spend time focusing on
>>> more advanced features like proxying, etc.
>>>
>>> Now, let me take a moment to address some the concerns that I'm sure
>>> are going to come out of this.
>>>
>>> I'm sure that someone will object to having to run a repository
>>> process.
>>>
>> I don't believe this will be the case if it is very simple, and not
>> very onerous. If starting from scratch setting up a little Java
>> application should be easier then setting up Apache. This is the goal
>> I would think, at least for things that I'm working on for clients.
>>
>>
>>> Well, aside from the file wagon (which doesn't make for a
>>> very good remote repository :-)
>>>
>> It does if you use a shared file system, many people actually use
>> this. And simple Window file perms work here to protect it.
>>
>
> How do you deal with concurrent writes?
>
That's a nightmare problem with the local repository anyway.
One team of ours had to scrap switching to Maven as it filled the disk
on their shared homes drive... and if they changed the system default to
use a common local repository they kept on getting broken builds from
two people installing the same (usually snapshot) artifact at the same time!
It's more of a problem for continuous integration servers that run
builds in parallel.
However the concurrent write problem is solved for remote repositories,
please solve it for local repositories as well!
>
>>> , all of them require some sort of
>>> server somewhere. Granted, a lot of people have sshd or httpd or ftpd
>>> running so it's not an extra process, but there's still _something_
>>> running on the other end no matter what. Also, I'd be pretty
>>> surprised to find that a significant portion of the people running a
>>> remote repository weren't running a servlet container already as well.
>>> Plus, there's always jetty or winstone if you want a quick install.
>>>
>>>
>> No argument that in the very near future I don't think anyone will
>> use a Maven repository without a front-end application. Web servers
>> are just too stupid, security is annoying, you have no transactional
>> behaviour, and you have to expose the internal structure.
>>
>>
>>> I'm also pretty sure that there's going to be some question of
>>> backwards compatibility. Well, seeing that I'm suggesting a RESTful
>>> service, it could have the exact same structure as what's being used
>>> now. I'm not entirely sure I'd recommend that, but it _could_. If it
>>> didn't you could always just add a new layout.
>>>
>>>
>> The repository managers will have an API, and can be exposed via REST
>> which will end up being one of the favored modes of operation. But I
>> see applications interacting directly with client side APIs to get
>> things done. Like Maven deployments, releases, searching, what have you.
>>
>
> This seems like it'd end up being problematic for a couple of reasons.
> The first is that when you say that it _can_ be exposed via REST this
> implies too much flexibility in what the resource URIs look like. To
> provide a decent user experience from both the application and the
> browser, there has to be some standardization for the rest api. Not
> that the current layout doesn't have a standard interface, but the
> format of the results for directory listings and the URIs for
> additional functionality would end up being all over the place.
>
> The other issue is that, from a developer perspective, I'd rather
> there not be a standard java api. If the job of a repository is to
> serve artifacts, that should be the only contract to which I'm bound
> (especially if the maven code is still compiling with 1.4). Unless
> there's a really compelling reason to support other transports, any
> additional api just adds another layer. Of course, the maven-built RI
> could add whatever api it wants, but I can't think of a scenario in
> which you'd need to support its invocation from anything other than
> the transport.
>
>
>>> Now, what seems like it'd be the highest hurdle: the central
>>> repository. The content would have to be migrated and it'd have to be
>>> hosted. Of course, I don't really have a good answer for either.
>>> Migration seemed to be a pain the first time, but at least the
>>> community would have some experience... :-)
>>>
>>>
>> Nothing would need to be migrated, there's not reason that the call
>> that is currently made could not be adapted. With a simple web server
>> there are issues of migration, with an application then you just map
>> the URL to what the application knows and respond as the client
>> expects. Not actually having a real application on repositories is
>> limiting but we evolved in a normal way I think and this is the next
>> step for Maven.
>>
>> But the case that Atlassian wants solved would be very simple with
>> something like Proximity even today. One simple access controller
>> that blocked the source jars for particular users and you're set.
>>
>>
>>> So, that's it. Any thoughts?
>>>
>>> On 8/22/07, James William Dumay <ja...@atlassian.com> wrote:
>>>
>>>> Jason,
>>>>
>>>>> So why can't it all be in one repository? You have people who buy
>>>>> your products with a non-source license and you give them access to
>>>>> binaries from a Maven repository instead of an installer? Or you
>>>>> have
>>>>> updaters that use a Maven repository so you only need the binaries
>>>>> for this? This last case I could understand.
>>>>>
>>>>>
>>>> We cannot have just one repository and give access to paying
>>>> customers
>>>> because we also have a community of plugin developers which rely on
>>>> various artifacts that are part of our products.
>>>>
>>>> This would mean for every developer that would like to write a
>>>> plugin we
>>>> would have to give them access to the repository - this would include
>>>> our private sources.
>>>>
>>>>
>>>>> For your own artifacts that you are producing why do they need to be
>>>>> public at all? I ask because I do something similar and I don't
>>>>> understand what it is you're actually trying to accomplish. This
>>>>> aside it still doesn't change the fact Maven wasn't designed to have
>>>>> the primary artifact separated from the secondaries and simply
>>>>> causes
>>>>> a discontinuity in tooling. This is currently how it works. For
>>>>> anyone trying to debug their copy of an Atlassian product the Maven
>>>>> IDE integration wouldn't work.
>>>>>
>>>> The jars that are released to public without their sources and
>>>> javadocs
>>>> are not something the developers building and modifying the products
>>>> would be wanting source and javadocs for anyway. They are there
>>>> simply
>>>> deployed so that they can build the source code that they are
>>>> licensed
>>>> to modify. Internally, our developers would be able to access the
>>>> primary artifacts, sources, javadocs and assemblies.
>>>>
>>>>
>>>>> In your case would it not be easier to give people read-only access
>>>>> to the SCM, they build it as you build it and have access to a
>>>>> password protected repository that contains everything required for
>>>>> building. I don't understand your need to separate it the binaries
>>>>> from javadoc and sources.
>>>>>
>>>> Customers currently download the sources from the website, not
>>>> checking
>>>> them out from the repository. Having a password protected repository
>>>> would mean we would have to add more admin overhead to the Developer
>>>> Network team.
>>>>
>>>> I believe a user should be able to configure their maven builds to
>>>> allow
>>>> the deployment of attached artifacts to a specified repository. Users
>>>> who would use this feature would have to be aware of the
>>>> consequences of
>>>> splitting these artifacts away from their primary artifacts.
>>>>
>>>> James
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>> --
>>> Gregory Kick
>>> http://kickstyle.net/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Gregory Kick <gk...@gmail.com>.
On 8/22/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
>
> > Ok, so I'm coming to the conversation slightly late in the game, but
> > all of this discussion reminds me of something that's been in the back
> > of my mind for sometime. With all of the effort put forth in the
> > various repository managers, front-ends, proxies, mirrors, etc. why
> > doesn't the whole repository mechanism get a bit more intelligence in
> > order to solve some of these basic problems?
> >
>
> Exactly. In short they are. Trying to do anything reasonably
> intelligent with an unintelligent mechanism like a simple web server
> is very hard.
>
> > AFAIK (and correct me if i'm wrong), http is almost exclusively for
> > fetching artifacts, so a basic RESTful service could go a long way
> > towards standardizing some of the things that seem to be pretty
> > commonly needed. For example:
> > - authentication/authorization, which is what would solve the problem
> > discussed in this thread
> > - basic listing (e.g. what artifacts exist for a given group)
> > - search (depending on how much logic you really want to give to the
> > repository)
> > - standard, machine-readable output. no more scraping apache
> > directory listings...
> > - consistent, accurate, real-time metadata
> > - server-side deployment validation/atomic deploys
> >
> > The list could probably go on, but those are just a few quick ideas.
> > It just seems like there's functionality that I would like to be able
> > to expect from a repository, but don't get because it's not really
> > anything more than a big directory. Then, all of the more
> > sophisticated repository management tools can spend time focusing on
> > more advanced features like proxying, etc.
> >
> > Now, let me take a moment to address some the concerns that I'm sure
> > are going to come out of this.
> >
> > I'm sure that someone will object to having to run a repository
> > process.
>
> I don't believe this will be the case if it is very simple, and not
> very onerous. If starting from scratch setting up a little Java
> application should be easier then setting up Apache. This is the goal
> I would think, at least for things that I'm working on for clients.
>
> > Well, aside from the file wagon (which doesn't make for a
> > very good remote repository :-)
>
> It does if you use a shared file system, many people actually use
> this. And simple Window file perms work here to protect it.
How do you deal with concurrent writes?
>
> > , all of them require some sort of
> > server somewhere. Granted, a lot of people have sshd or httpd or ftpd
> > running so it's not an extra process, but there's still _something_
> > running on the other end no matter what. Also, I'd be pretty
> > surprised to find that a significant portion of the people running a
> > remote repository weren't running a servlet container already as well.
> > Plus, there's always jetty or winstone if you want a quick install.
> >
>
> No argument that in the very near future I don't think anyone will
> use a Maven repository without a front-end application. Web servers
> are just too stupid, security is annoying, you have no transactional
> behaviour, and you have to expose the internal structure.
>
> > I'm also pretty sure that there's going to be some question of
> > backwards compatibility. Well, seeing that I'm suggesting a RESTful
> > service, it could have the exact same structure as what's being used
> > now. I'm not entirely sure I'd recommend that, but it _could_. If it
> > didn't you could always just add a new layout.
> >
>
> The repository managers will have an API, and can be exposed via REST
> which will end up being one of the favored modes of operation. But I
> see applications interacting directly with client side APIs to get
> things done. Like Maven deployments, releases, searching, what have you.
This seems like it'd end up being problematic for a couple of reasons.
The first is that when you say that it _can_ be exposed via REST this
implies too much flexibility in what the resource URIs look like. To
provide a decent user experience from both the application and the
browser, there has to be some standardization for the rest api. Not
that the current layout doesn't have a standard interface, but the
format of the results for directory listings and the URIs for
additional functionality would end up being all over the place.
The other issue is that, from a developer perspective, I'd rather
there not be a standard java api. If the job of a repository is to
serve artifacts, that should be the only contract to which I'm bound
(especially if the maven code is still compiling with 1.4). Unless
there's a really compelling reason to support other transports, any
additional api just adds another layer. Of course, the maven-built RI
could add whatever api it wants, but I can't think of a scenario in
which you'd need to support its invocation from anything other than
the transport.
>
> > Now, what seems like it'd be the highest hurdle: the central
> > repository. The content would have to be migrated and it'd have to be
> > hosted. Of course, I don't really have a good answer for either.
> > Migration seemed to be a pain the first time, but at least the
> > community would have some experience... :-)
> >
>
> Nothing would need to be migrated, there's not reason that the call
> that is currently made could not be adapted. With a simple web server
> there are issues of migration, with an application then you just map
> the URL to what the application knows and respond as the client
> expects. Not actually having a real application on repositories is
> limiting but we evolved in a normal way I think and this is the next
> step for Maven.
>
> But the case that Atlassian wants solved would be very simple with
> something like Proximity even today. One simple access controller
> that blocked the source jars for particular users and you're set.
>
> > So, that's it. Any thoughts?
> >
> > On 8/22/07, James William Dumay <ja...@atlassian.com> wrote:
> >> Jason,
> >>> So why can't it all be in one repository? You have people who buy
> >>> your products with a non-source license and you give them access to
> >>> binaries from a Maven repository instead of an installer? Or you
> >>> have
> >>> updaters that use a Maven repository so you only need the binaries
> >>> for this? This last case I could understand.
> >>>
> >>
> >> We cannot have just one repository and give access to paying
> >> customers
> >> because we also have a community of plugin developers which rely on
> >> various artifacts that are part of our products.
> >>
> >> This would mean for every developer that would like to write a
> >> plugin we
> >> would have to give them access to the repository - this would include
> >> our private sources.
> >>
> >>> For your own artifacts that you are producing why do they need to be
> >>> public at all? I ask because I do something similar and I don't
> >>> understand what it is you're actually trying to accomplish. This
> >>> aside it still doesn't change the fact Maven wasn't designed to have
> >>> the primary artifact separated from the secondaries and simply
> >>> causes
> >>> a discontinuity in tooling. This is currently how it works. For
> >>> anyone trying to debug their copy of an Atlassian product the Maven
> >>> IDE integration wouldn't work.
> >>
> >> The jars that are released to public without their sources and
> >> javadocs
> >> are not something the developers building and modifying the products
> >> would be wanting source and javadocs for anyway. They are there
> >> simply
> >> deployed so that they can build the source code that they are
> >> licensed
> >> to modify. Internally, our developers would be able to access the
> >> primary artifacts, sources, javadocs and assemblies.
> >>
> >>> In your case would it not be easier to give people read-only access
> >>> to the SCM, they build it as you build it and have access to a
> >>> password protected repository that contains everything required for
> >>> building. I don't understand your need to separate it the binaries
> >>> from javadoc and sources.
> >>
> >> Customers currently download the sources from the website, not
> >> checking
> >> them out from the repository. Having a password protected repository
> >> would mean we would have to add more admin overhead to the Developer
> >> Network team.
> >>
> >> I believe a user should be able to configure their maven builds to
> >> allow
> >> the deployment of attached artifacts to a specified repository. Users
> >> who would use this feature would have to be aware of the
> >> consequences of
> >> splitting these artifacts away from their primary artifacts.
> >>
> >> James
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Gregory Kick
> > http://kickstyle.net/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Gregory Kick
http://kickstyle.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 22 Aug 07, at 8:24 AM 22 Aug 07, Gregory Kick wrote:
> Ok, so I'm coming to the conversation slightly late in the game, but
> all of this discussion reminds me of something that's been in the back
> of my mind for sometime. With all of the effort put forth in the
> various repository managers, front-ends, proxies, mirrors, etc. why
> doesn't the whole repository mechanism get a bit more intelligence in
> order to solve some of these basic problems?
>
Exactly. In short they are. Trying to do anything reasonably
intelligent with an unintelligent mechanism like a simple web server
is very hard.
> AFAIK (and correct me if i'm wrong), http is almost exclusively for
> fetching artifacts, so a basic RESTful service could go a long way
> towards standardizing some of the things that seem to be pretty
> commonly needed. For example:
> - authentication/authorization, which is what would solve the problem
> discussed in this thread
> - basic listing (e.g. what artifacts exist for a given group)
> - search (depending on how much logic you really want to give to the
> repository)
> - standard, machine-readable output. no more scraping apache
> directory listings...
> - consistent, accurate, real-time metadata
> - server-side deployment validation/atomic deploys
>
> The list could probably go on, but those are just a few quick ideas.
> It just seems like there's functionality that I would like to be able
> to expect from a repository, but don't get because it's not really
> anything more than a big directory. Then, all of the more
> sophisticated repository management tools can spend time focusing on
> more advanced features like proxying, etc.
>
> Now, let me take a moment to address some the concerns that I'm sure
> are going to come out of this.
>
> I'm sure that someone will object to having to run a repository
> process.
I don't believe this will be the case if it is very simple, and not
very onerous. If starting from scratch setting up a little Java
application should be easier then setting up Apache. This is the goal
I would think, at least for things that I'm working on for clients.
> Well, aside from the file wagon (which doesn't make for a
> very good remote repository :-)
It does if you use a shared file system, many people actually use
this. And simple Window file perms work here to protect it.
> , all of them require some sort of
> server somewhere. Granted, a lot of people have sshd or httpd or ftpd
> running so it's not an extra process, but there's still _something_
> running on the other end no matter what. Also, I'd be pretty
> surprised to find that a significant portion of the people running a
> remote repository weren't running a servlet container already as well.
> Plus, there's always jetty or winstone if you want a quick install.
>
No argument that in the very near future I don't think anyone will
use a Maven repository without a front-end application. Web servers
are just too stupid, security is annoying, you have no transactional
behaviour, and you have to expose the internal structure.
> I'm also pretty sure that there's going to be some question of
> backwards compatibility. Well, seeing that I'm suggesting a RESTful
> service, it could have the exact same structure as what's being used
> now. I'm not entirely sure I'd recommend that, but it _could_. If it
> didn't you could always just add a new layout.
>
The repository managers will have an API, and can be exposed via REST
which will end up being one of the favored modes of operation. But I
see applications interacting directly with client side APIs to get
things done. Like Maven deployments, releases, searching, what have you.
> Now, what seems like it'd be the highest hurdle: the central
> repository. The content would have to be migrated and it'd have to be
> hosted. Of course, I don't really have a good answer for either.
> Migration seemed to be a pain the first time, but at least the
> community would have some experience... :-)
>
Nothing would need to be migrated, there's not reason that the call
that is currently made could not be adapted. With a simple web server
there are issues of migration, with an application then you just map
the URL to what the application knows and respond as the client
expects. Not actually having a real application on repositories is
limiting but we evolved in a normal way I think and this is the next
step for Maven.
But the case that Atlassian wants solved would be very simple with
something like Proximity even today. One simple access controller
that blocked the source jars for particular users and you're set.
> So, that's it. Any thoughts?
>
> On 8/22/07, James William Dumay <ja...@atlassian.com> wrote:
>> Jason,
>>> So why can't it all be in one repository? You have people who buy
>>> your products with a non-source license and you give them access to
>>> binaries from a Maven repository instead of an installer? Or you
>>> have
>>> updaters that use a Maven repository so you only need the binaries
>>> for this? This last case I could understand.
>>>
>>
>> We cannot have just one repository and give access to paying
>> customers
>> because we also have a community of plugin developers which rely on
>> various artifacts that are part of our products.
>>
>> This would mean for every developer that would like to write a
>> plugin we
>> would have to give them access to the repository - this would include
>> our private sources.
>>
>>> For your own artifacts that you are producing why do they need to be
>>> public at all? I ask because I do something similar and I don't
>>> understand what it is you're actually trying to accomplish. This
>>> aside it still doesn't change the fact Maven wasn't designed to have
>>> the primary artifact separated from the secondaries and simply
>>> causes
>>> a discontinuity in tooling. This is currently how it works. For
>>> anyone trying to debug their copy of an Atlassian product the Maven
>>> IDE integration wouldn't work.
>>
>> The jars that are released to public without their sources and
>> javadocs
>> are not something the developers building and modifying the products
>> would be wanting source and javadocs for anyway. They are there
>> simply
>> deployed so that they can build the source code that they are
>> licensed
>> to modify. Internally, our developers would be able to access the
>> primary artifacts, sources, javadocs and assemblies.
>>
>>> In your case would it not be easier to give people read-only access
>>> to the SCM, they build it as you build it and have access to a
>>> password protected repository that contains everything required for
>>> building. I don't understand your need to separate it the binaries
>>> from javadoc and sources.
>>
>> Customers currently download the sources from the website, not
>> checking
>> them out from the repository. Having a password protected repository
>> would mean we would have to add more admin overhead to the Developer
>> Network team.
>>
>> I believe a user should be able to configure their maven builds to
>> allow
>> the deployment of attached artifacts to a specified repository. Users
>> who would use this feature would have to be aware of the
>> consequences of
>> splitting these artifacts away from their primary artifacts.
>>
>> James
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> Gregory Kick
> http://kickstyle.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Gregory Kick <gk...@gmail.com>.
Ok, so I'm coming to the conversation slightly late in the game, but
all of this discussion reminds me of something that's been in the back
of my mind for sometime. With all of the effort put forth in the
various repository managers, front-ends, proxies, mirrors, etc. why
doesn't the whole repository mechanism get a bit more intelligence in
order to solve some of these basic problems?
AFAIK (and correct me if i'm wrong), http is almost exclusively for
fetching artifacts, so a basic RESTful service could go a long way
towards standardizing some of the things that seem to be pretty
commonly needed. For example:
- authentication/authorization, which is what would solve the problem
discussed in this thread
- basic listing (e.g. what artifacts exist for a given group)
- search (depending on how much logic you really want to give to the
repository)
- standard, machine-readable output. no more scraping apache
directory listings...
- consistent, accurate, real-time metadata
- server-side deployment validation/atomic deploys
The list could probably go on, but those are just a few quick ideas.
It just seems like there's functionality that I would like to be able
to expect from a repository, but don't get because it's not really
anything more than a big directory. Then, all of the more
sophisticated repository management tools can spend time focusing on
more advanced features like proxying, etc.
Now, let me take a moment to address some the concerns that I'm sure
are going to come out of this.
I'm sure that someone will object to having to run a repository
process. Well, aside from the file wagon (which doesn't make for a
very good remote repository :-), all of them require some sort of
server somewhere. Granted, a lot of people have sshd or httpd or ftpd
running so it's not an extra process, but there's still _something_
running on the other end no matter what. Also, I'd be pretty
surprised to find that a significant portion of the people running a
remote repository weren't running a servlet container already as well.
Plus, there's always jetty or winstone if you want a quick install.
I'm also pretty sure that there's going to be some question of
backwards compatibility. Well, seeing that I'm suggesting a RESTful
service, it could have the exact same structure as what's being used
now. I'm not entirely sure I'd recommend that, but it _could_. If it
didn't you could always just add a new layout.
Now, what seems like it'd be the highest hurdle: the central
repository. The content would have to be migrated and it'd have to be
hosted. Of course, I don't really have a good answer for either.
Migration seemed to be a pain the first time, but at least the
community would have some experience... :-)
So, that's it. Any thoughts?
On 8/22/07, James William Dumay <ja...@atlassian.com> wrote:
> Jason,
> > So why can't it all be in one repository? You have people who buy
> > your products with a non-source license and you give them access to
> > binaries from a Maven repository instead of an installer? Or you have
> > updaters that use a Maven repository so you only need the binaries
> > for this? This last case I could understand.
> >
>
> We cannot have just one repository and give access to paying customers
> because we also have a community of plugin developers which rely on
> various artifacts that are part of our products.
>
> This would mean for every developer that would like to write a plugin we
> would have to give them access to the repository - this would include
> our private sources.
>
> > For your own artifacts that you are producing why do they need to be
> > public at all? I ask because I do something similar and I don't
> > understand what it is you're actually trying to accomplish. This
> > aside it still doesn't change the fact Maven wasn't designed to have
> > the primary artifact separated from the secondaries and simply causes
> > a discontinuity in tooling. This is currently how it works. For
> > anyone trying to debug their copy of an Atlassian product the Maven
> > IDE integration wouldn't work.
>
> The jars that are released to public without their sources and javadocs
> are not something the developers building and modifying the products
> would be wanting source and javadocs for anyway. They are there simply
> deployed so that they can build the source code that they are licensed
> to modify. Internally, our developers would be able to access the
> primary artifacts, sources, javadocs and assemblies.
>
> > In your case would it not be easier to give people read-only access
> > to the SCM, they build it as you build it and have access to a
> > password protected repository that contains everything required for
> > building. I don't understand your need to separate it the binaries
> > from javadoc and sources.
>
> Customers currently download the sources from the website, not checking
> them out from the repository. Having a password protected repository
> would mean we would have to add more admin overhead to the Developer
> Network team.
>
> I believe a user should be able to configure their maven builds to allow
> the deployment of attached artifacts to a specified repository. Users
> who would use this feature would have to be aware of the consequences of
> splitting these artifacts away from their primary artifacts.
>
> James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Gregory Kick
http://kickstyle.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by James William Dumay <ja...@atlassian.com>.
Jason,
> So why can't it all be in one repository? You have people who buy
> your products with a non-source license and you give them access to
> binaries from a Maven repository instead of an installer? Or you have
> updaters that use a Maven repository so you only need the binaries
> for this? This last case I could understand.
>
We cannot have just one repository and give access to paying customers
because we also have a community of plugin developers which rely on
various artifacts that are part of our products.
This would mean for every developer that would like to write a plugin we
would have to give them access to the repository - this would include
our private sources.
> For your own artifacts that you are producing why do they need to be
> public at all? I ask because I do something similar and I don't
> understand what it is you're actually trying to accomplish. This
> aside it still doesn't change the fact Maven wasn't designed to have
> the primary artifact separated from the secondaries and simply causes
> a discontinuity in tooling. This is currently how it works. For
> anyone trying to debug their copy of an Atlassian product the Maven
> IDE integration wouldn't work.
The jars that are released to public without their sources and javadocs
are not something the developers building and modifying the products
would be wanting source and javadocs for anyway. They are there simply
deployed so that they can build the source code that they are licensed
to modify. Internally, our developers would be able to access the
primary artifacts, sources, javadocs and assemblies.
> In your case would it not be easier to give people read-only access
> to the SCM, they build it as you build it and have access to a
> password protected repository that contains everything required for
> building. I don't understand your need to separate it the binaries
> from javadoc and sources.
Customers currently download the sources from the website, not checking
them out from the repository. Having a password protected repository
would mean we would have to add more admin overhead to the Developer
Network team.
I believe a user should be able to configure their maven builds to allow
the deployment of attached artifacts to a specified repository. Users
who would use this feature would have to be aware of the consequences of
splitting these artifacts away from their primary artifacts.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Aug 07, at 5:43 PM 21 Aug 07, James William Dumay wrote:
>
>> Sorry if I'm missing something but why they can't just publish
>> everything to their private repo and just mirror things
>> they want share to the public repository afterwards?
>
> Sure, that could be done, however, this is yet more infrastructure
> that
> needs to be written and maintained in the build environment.
>
>> As being Maven user (I'm from Apache Cocoon) I support Jason's
>> opinion here. If you have very specific requirements that
>> could be fulfilled by existing tools (few lines of script) just
>> use them and don't pollute other tools with your
>> specific needs.
>
> Why use yet another external tool?
>
>> From the maven website itself:
> "Maven can manage a project's build, reporting and documentation
> from a
> central piece of information."
>
> So, is the information for the control of artifact deployment not
> within
> the scope of the projects mission? Isn't maven supposed to manage my
> projects build?
>
> As you know, Maven already does this in a limited sense - you can
> deploy
> whole projects to one repository or another via specifying a
> distribution management information in your pom.
>
It does this for the purpose of 1) staging, and 2) supporting more
then a release and snapshot repository. We fully support multiple
repositories as normally I recommend a setup with 5 repositories.
Separating the primary and secondary artifacts is a very different
use case, and one we never considered supporting.
> The real use case here is giving developers the flexibility to control
> what kinds of artifacts go where and subsequently who has access to
> specific artifact types.
>
That's not a use case, that's simply how you would prefer to do this.
> For example, at Atlassian, we have a model where customers pay for
> a license and
> receive our source code. Customers can then use Maven to resolve
> dependant artifacts from our public maven repository and build the
> entire product.
>
So why can't it all be in one repository? You have people who buy
your products with a non-source license and you give them access to
binaries from a Maven repository instead of an installer? Or you have
updaters that use a Maven repository so you only need the binaries
for this? This last case I could understand.
> For IP reasons, we cannot publish the source and javadoc
> artifacts publicly along with the jar artifact of which our internal
> development staff and contractors need to use.
For your own artifacts that you are producing why do they need to be
public at all? I ask because I do something similar and I don't
understand what it is you're actually trying to accomplish. This
aside it still doesn't change the fact Maven wasn't designed to have
the primary artifact separated from the secondaries and simply causes
a discontinuity in tooling. This is currently how it works. For
anyone trying to debug their copy of an Atlassian product the Maven
IDE integration wouldn't work.
>
> I think this would be a fairly common use case among other
> companies with
> similar models and if maven is a build management tool - why can't
> it manage the
> needs of commercial products too?
>
Sure, we have no problem supporting commercial products. But it does
not logically follow that because we don't allow the separation of
primary and secondary artifacts that we don't support commercial
products.
In your case would it not be easier to give people read-only access
to the SCM, they build it as you build it and have access to a
password protected repository that contains everything required for
building. I don't understand your need to separate it the binaries
from javadoc and sources.
> Thanks
> --
> James William Dumay <ja...@atlassian.com>
> Atlassian Software Systems
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by James William Dumay <ja...@atlassian.com>.
> Sorry if I'm missing something but why they can't just publish everything to their private repo and just mirror things
> they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more infrastructure that
needs to be written and maintained in the build environment.
> As being Maven user (I'm from Apache Cocoon) I support Jason's opinion here. If you have very specific requirements that
> could be fulfilled by existing tools (few lines of script) just use them and don't pollute other tools with your
> specific needs.
Why use yet another external tool?
>>From the maven website itself:
"Maven can manage a project's build, reporting and documentation from a
central piece of information."
So, is the information for the control of artifact deployment not within
the scope of the projects mission? Isn't maven supposed to manage my
projects build?
As you know, Maven already does this in a limited sense - you can deploy
whole projects to one repository or another via specifying a
distribution management information in your pom.
The real use case here is giving developers the flexibility to control
what kinds of artifacts go where and subsequently who has access to
specific artifact types.
For example, at Atlassian, we have a model where customers pay for a license and
receive our source code. Customers can then use Maven to resolve
dependant artifacts from our public maven repository and build the entire product.
For IP reasons, we cannot publish the source and javadoc
artifacts publicly along with the jar artifact of which our internal
development staff and contractors need to use.
I think this would be a fairly common use case among other companies with
similar models and if maven is a build management tool - why can't it manage the
needs of commercial products too?
Thanks
--
James William Dumay <ja...@atlassian.com>
Atlassian Software Systems
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Aug 07, at 4:58 PM 21 Aug 07, Brett Porter wrote:
>
> On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
>
>> (I'm resending this mail from another account because previous one
>> seems to be stuck in moderation queue)
>>
>> Brian E. Fox pisze:
>>> I believe this came from Atlassian. (I386 on irc). They ship
>>> their jars
>>> and javadocs to users who want to write plugins etc, but the sources
>>> stay internal (or to paying customers I think).
>>
>> Sorry if I'm missing something but why they can't just publish
>> everything to their private repo and just mirror things
>> they want share to the public repository afterwards?
>
> This was my initial response too.
>
>>
>> As being Maven user (I'm from Apache Cocoon) I support Jason's
>> opinion here. If you have very specific requirements that
>> could be fulfilled by existing tools (few lines of script) just
>> use them and don't pollute other tools with your
>> specific needs.
>
> This solution is easier for the end user than having to write syncs
> with includes/excludes themselves. It all gets done in one hit.
>
> I'm not fan of featuritis, but it sounded like a valid use case,
> and since it gives the same net effect and doesn't affect any
> backwards compatibility I thought it was worth going ahead with.
>
I don't think applying them is a good idea. Any separation of the
primary and secondary artifacts will cause a problem and I don't see
any value in doing so, it makes tooling harder and will only cause
confusion. So for me it's a -1.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Aug 07, at 5:01 PM 21 Aug 07, Brian E. Fox wrote:
>> I'm not fan of featuritis, but it sounded like a valid use case, and
>> since it gives the same net effect and doesn't affect any backwards
>> compatibility I thought it was worth going ahead with.
>
> Same here. There is already a concept of attached artifacts and
> there is
> a parameter for an alternateDeployRepo, this is just expanding a
> little
> to combine those comcepts.
>
This is for the whole deployment of said artifact. Not to split up
the deployment. Everything we do assumes joint deployment and I see
zero value in allowing the separation and just makes everything
related to the relationship between primary and secondary artifacts
harder. Based on the coordinate of the primary you should be able to
find/search for the secondaries. We'll just end up with a clusterfuck
changing that.
> --Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>I'm not fan of featuritis, but it sounded like a valid use case, and
>since it gives the same net effect and doesn't affect any backwards
>compatibility I thought it was worth going ahead with.
Same here. There is already a concept of attached artifacts and there is
a parameter for an alternateDeployRepo, this is just expanding a little
to combine those comcepts.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Brett Porter <br...@apache.org>.
On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
> (I'm resending this mail from another account because previous one
> seems to be stuck in moderation queue)
>
> Brian E. Fox pisze:
>> I believe this came from Atlassian. (I386 on irc). They ship their
>> jars
>> and javadocs to users who want to write plugins etc, but the sources
>> stay internal (or to paying customers I think).
>
> Sorry if I'm missing something but why they can't just publish
> everything to their private repo and just mirror things
> they want share to the public repository afterwards?
This was my initial response too.
>
> As being Maven user (I'm from Apache Cocoon) I support Jason's
> opinion here. If you have very specific requirements that
> could be fulfilled by existing tools (few lines of script) just use
> them and don't pollute other tools with your
> specific needs.
This solution is easier for the end user than having to write syncs
with includes/excludes themselves. It all gets done in one hit.
I'm not fan of featuritis, but it sounded like a valid use case, and
since it gives the same net effect and doesn't affect any backwards
compatibility I thought it was worth going ahead with.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
(I'm resending this mail from another account because previous one seems to be stuck in moderation queue)
Brian E. Fox pisze:
> I believe this came from Atlassian. (I386 on irc). They ship their jars
> and javadocs to users who want to write plugins etc, but the sources
> stay internal (or to paying customers I think).
Sorry if I'm missing something but why they can't just publish everything to their private repo and just mirror things
they want share to the public repository afterwards?
As being Maven user (I'm from Apache Cocoon) I support Jason's opinion here. If you have very specific requirements that
could be fulfilled by existing tools (few lines of script) just use them and don't pollute other tools with your
specific needs.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: http://jira.codehaus.org/browse/MNG-3151
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
I believe this came from Atlassian. (I386 on irc). They ship their jars
and javadocs to users who want to write plugins etc, but the sources
stay internal (or to paying customers I think).
-----Original Message-----
From: Paul Gier [mailto:pgier@redhat.com]
Sent: Tuesday, August 21, 2007 3:02 PM
To: Maven Developers List
Subject: Re: http://jira.codehaus.org/browse/MNG-3151
The use case seems to be for non open source projects. They want to
distribute
their binaries and jars publicly, but keep the sources internal. Not
that I
agree with this practice, but I'm guessing that is one reason for these
requests.
Eric Redmond wrote:
> On 8/21/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Jason van Zyl ha scritto:
>>> I'm not sure this is something we want to encourage before the
patches
>>> are applied. Keeping the sources and javadoc JARs together seems
like
>>> a good thing to do. The sources and javadocs located in different
>>> locations doesn't seem to make much sense to me and there's no real
>>> explanation within the report.
>>>
>> I see there are 4 open bugs depending on this feature request:
>>
>> http://jira.codehaus.org/browse/MASSEMBLY-231
>> http://jira.codehaus.org/browse/MSOURCES-20
>> http://jira.codehaus.org/browse/MJAVADOC-142
>> http://jira.codehaus.org/browse/MDEPLOY-61
>
>
> These bugs are just extensions of the same feature request,
effectively
> these all constitute a single feature: "moving secondary artifacts to
an
> alternate repository."
>
> This seems to me to be separation for the sake of separation, with no
> existing use-case. I'm going to have to side with Jason in this one.
>
> This does not seem only related to javadocs and source jars. What kind
>> of "real explanation" do you expect for a similar feature request?
>>
>> IMHO adding a feature does not mean "encouraging" its usage: it
simply
>> means make it possible (you know there are always corner cases when
>> using maven).
>>
>> What problems do you see in applying this patch apart the
encouragement
>> issue?
>>
>> Stefano
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Paul Gier <pg...@redhat.com>.
The use case seems to be for non open source projects. They want to distribute
their binaries and jars publicly, but keep the sources internal. Not that I
agree with this practice, but I'm guessing that is one reason for these requests.
Eric Redmond wrote:
> On 8/21/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Jason van Zyl ha scritto:
>>> I'm not sure this is something we want to encourage before the patches
>>> are applied. Keeping the sources and javadoc JARs together seems like
>>> a good thing to do. The sources and javadocs located in different
>>> locations doesn't seem to make much sense to me and there's no real
>>> explanation within the report.
>>>
>> I see there are 4 open bugs depending on this feature request:
>>
>> http://jira.codehaus.org/browse/MASSEMBLY-231
>> http://jira.codehaus.org/browse/MSOURCES-20
>> http://jira.codehaus.org/browse/MJAVADOC-142
>> http://jira.codehaus.org/browse/MDEPLOY-61
>
>
> These bugs are just extensions of the same feature request, effectively
> these all constitute a single feature: "moving secondary artifacts to an
> alternate repository."
>
> This seems to me to be separation for the sake of separation, with no
> existing use-case. I'm going to have to side with Jason in this one.
>
> This does not seem only related to javadocs and source jars. What kind
>> of "real explanation" do you expect for a similar feature request?
>>
>> IMHO adding a feature does not mean "encouraging" its usage: it simply
>> means make it possible (you know there are always corner cases when
>> using maven).
>>
>> What problems do you see in applying this patch apart the encouragement
>> issue?
>>
>> Stefano
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Eric Redmond <er...@gmail.com>.
On 8/21/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> Jason van Zyl ha scritto:
> > I'm not sure this is something we want to encourage before the patches
> > are applied. Keeping the sources and javadoc JARs together seems like
> > a good thing to do. The sources and javadocs located in different
> > locations doesn't seem to make much sense to me and there's no real
> > explanation within the report.
> >
> I see there are 4 open bugs depending on this feature request:
>
> http://jira.codehaus.org/browse/MASSEMBLY-231
> http://jira.codehaus.org/browse/MSOURCES-20
> http://jira.codehaus.org/browse/MJAVADOC-142
> http://jira.codehaus.org/browse/MDEPLOY-61
These bugs are just extensions of the same feature request, effectively
these all constitute a single feature: "moving secondary artifacts to an
alternate repository."
This seems to me to be separation for the sake of separation, with no
existing use-case. I'm going to have to side with Jason in this one.
This does not seem only related to javadocs and source jars. What kind
> of "real explanation" do you expect for a similar feature request?
>
> IMHO adding a feature does not mean "encouraging" its usage: it simply
> means make it possible (you know there are always corner cases when
> using maven).
>
> What problems do you see in applying this patch apart the encouragement
> issue?
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Eric Redmond
http://blog.propellors.net
Re: http://jira.codehaus.org/browse/MNG-3151
Posted by Stefano Bagnara <ap...@bago.org>.
Jason van Zyl ha scritto:
> I'm not sure this is something we want to encourage before the patches
> are applied. Keeping the sources and javadoc JARs together seems like
> a good thing to do. The sources and javadocs located in different
> locations doesn't seem to make much sense to me and there's no real
> explanation within the report.
>
I see there are 4 open bugs depending on this feature request:
http://jira.codehaus.org/browse/MASSEMBLY-231
http://jira.codehaus.org/browse/MSOURCES-20
http://jira.codehaus.org/browse/MJAVADOC-142
http://jira.codehaus.org/browse/MDEPLOY-61
This does not seem only related to javadocs and source jars. What kind
of "real explanation" do you expect for a similar feature request?
IMHO adding a feature does not mean "encouraging" its usage: it simply
means make it possible (you know there are always corner cases when
using maven).
What problems do you see in applying this patch apart the encouragement
issue?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org