Repository Changes

[Shane Isbell <sh...@gmail.com>]

Some background info on the repository changes:

http://www.jroller.com/random7/entry/apache_nmaven_repository_structure_and

Shane

Re: Repository Changes

[Shane Isbell <sh...@gmail.com>]

Comments in line.

On 8/8/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 8 Aug 07, at 2:39 AM 8 Aug 07, Shane Isbell wrote:
>
> > I tend to agree: NMaven's primary target are those development
> > environments
> > using both .NET and Java. It is an important niche area that
> > Microsoft and
> > Ant are not able to address. Once we have a new API, I have no
> > problems
> > moving to that. The primary things I need are to be able to handle
> > multiple
> > classifiers,
>
> That we can't currently support but could be fixed.
>
> > not use a version in the file-name
>
> That can already be done, Dan Fabulich did for his .NET work.
>
> > and be able to support a
> > separate executable application space.
>
> You mean running the resolver in a process outside of Maven? Why do
> you need that?
>

No it's not running the resolver outside of Maven. This is the private
application base (pab) area, where .NET executables and their
dependencies are. For instance, when NMaven downloads
NMaven.Plugin.Loader.exe, it places a copy in a directory within the
pab, along with its dependencies. So now there is a versioned location
for executing the assembly. It's not that I would expect a resolver to
do this, but rather that the use of the resolver API would not
preclude it.

> > The resolver also needs to be able to
> > pull in multiple versions of the same artifact, as the CLR may use
> > both in
> > different application loaders for each version.
>
> What restrictions are in the resolver that prevent you from doing
> that? Or you mean pulling down [a0, a1, a2] in one shot?

We need to be able to pull down in one shot; but it's a little more
complicated than Java. If the dependent assembly is strong-named, all
versions of the same artifact (even multiple versions specified as
direct dependencies) need to be brought into the dependency set. If
the dependency is weak-named, then it could follow similar resolving
as the Java case.

There is also the need to allow the assembly provider to specify
whether the resolved assembly should also be installed within the
global assembly cache. I am not sure how this would fit - as a general
case - in an artifact component. It would involve some meta-data (I
currenty use net-dependencies.xml) and a post-resolve operation.

So for .NET, we need additional meta-data: requirements/classifier(s)
(Vendor/Framework Version), isSigned, isGacInstall

Shane

Re: Repository Changes

[Jason van Zyl <ja...@maven.org>]

On 8 Aug 07, at 2:39 AM 8 Aug 07, Shane Isbell wrote:

> I tend to agree: NMaven's primary target are those development  
> environments
> using both .NET and Java. It is an important niche area that  
> Microsoft and
> Ant are not able to address. Once we have a new API, I have no  
> problems
> moving to that. The primary things I need are to be able to handle  
> multiple
> classifiers,

That we can't currently support but could be fixed.

> not use a version in the file-name

That can already be done, Dan Fabulich did for his .NET work.

> and be able to support a
> separate executable application space.

You mean running the resolver in a process outside of Maven? Why do  
you need that?

> The resolver also needs to be able to
> pull in multiple versions of the same artifact, as the CLR may use  
> both in
> different application loaders for each version.

What restrictions are in the resolver that prevent you from doing  
that? Or you mean pulling down [a0, a1, a2] in one shot?

>
> Regards,
> Shane
>
>
> On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 8 Aug 07, at 1:46 AM 8 Aug 07, Shane Isbell wrote:
>>
>>> I'll tell them it works ;)
>>>
>>
>> Just note, I'm not trying to rain on your parade. I just think that a
>> new API we come up with will be able to support any end format, I
>> just don't see the benefit of RDF. If we're going to use something
>> unreadable we might as well just use a binary index :-)
>>
>> I think we can get the artifact api sorted out quickly and it would
>> be very nice to align everything back to something common and I agree
>> it needs to be robust and be flawless. I realize why you wanted/had
>> to use something else but in the long I think it will be confusing
>> for users. The 4 groups I know using NMaven are doing both Java
>> and .net at the same time. The POM is fundamental to Maven.
>>
>>> On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>>>>
>>>>
>>>> On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:
>>>>
>>>>> Some background info on the repository changes:
>>>>>
>>>>> http://www.jroller.com/random7/entry/
>>>>> apache_nmaven_repository_structure_and
>>>>>
>>>>>
>>>>
>>>> I wouldn't go veering off too far from the way Java Maven works  
>>>> as I
>>>> won't be too keen on integrating this back into the top-level  
>>>> project
>>>> being entirely different then the existing system. Using an  
>>>> entirely
>>>> different resolution mechanism  and a different local repository
>>>> format creating a dichotomy between Maven and NMaven.
>>>>
>>>> What do you tell people when they are accustom to Maven and then
>>>> start using NMaven and it works completely differently?
>>>>
>>>>> Shane
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder and PMC Chair, Apache Maven
>>>> jason at sonatype dot com
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>>
>>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Re: Repository Changes

[Shane Isbell <sh...@gmail.com>]

I tend to agree: NMaven's primary target are those development environments
using both .NET and Java. It is an important niche area that Microsoft and
Ant are not able to address. Once we have a new API, I have no problems
moving to that. The primary things I need are to be able to handle multiple
classifiers, not use a version in the file-name and be able to support a
separate executable application space. The resolver also needs to be able to
pull in multiple versions of the same artifact, as the CLR may use both in
different application loaders for each version.

Regards,
Shane


On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 8 Aug 07, at 1:46 AM 8 Aug 07, Shane Isbell wrote:
>
> > I'll tell them it works ;)
> >
>
> Just note, I'm not trying to rain on your parade. I just think that a
> new API we come up with will be able to support any end format, I
> just don't see the benefit of RDF. If we're going to use something
> unreadable we might as well just use a binary index :-)
>
> I think we can get the artifact api sorted out quickly and it would
> be very nice to align everything back to something common and I agree
> it needs to be robust and be flawless. I realize why you wanted/had
> to use something else but in the long I think it will be confusing
> for users. The 4 groups I know using NMaven are doing both Java
> and .net at the same time. The POM is fundamental to Maven.
>
> > On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
> >>
> >>
> >> On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:
> >>
> >>> Some background info on the repository changes:
> >>>
> >>> http://www.jroller.com/random7/entry/
> >>> apache_nmaven_repository_structure_and
> >>>
> >>>
> >>
> >> I wouldn't go veering off too far from the way Java Maven works as I
> >> won't be too keen on integrating this back into the top-level project
> >> being entirely different then the existing system. Using an entirely
> >> different resolution mechanism  and a different local repository
> >> format creating a dichotomy between Maven and NMaven.
> >>
> >> What do you tell people when they are accustom to Maven and then
> >> start using NMaven and it works completely differently?
> >>
> >>> Shane
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder and PMC Chair, Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >>
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>

Re: Repository Changes

[Jason van Zyl <ja...@maven.org>]

On 8 Aug 07, at 1:46 AM 8 Aug 07, Shane Isbell wrote:

> I'll tell them it works ;)
>

Just note, I'm not trying to rain on your parade. I just think that a  
new API we come up with will be able to support any end format, I  
just don't see the benefit of RDF. If we're going to use something  
unreadable we might as well just use a binary index :-)

I think we can get the artifact api sorted out quickly and it would  
be very nice to align everything back to something common and I agree  
it needs to be robust and be flawless. I realize why you wanted/had  
to use something else but in the long I think it will be confusing  
for users. The 4 groups I know using NMaven are doing both Java  
and .net at the same time. The POM is fundamental to Maven.

> On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:
>>
>>> Some background info on the repository changes:
>>>
>>> http://www.jroller.com/random7/entry/
>>> apache_nmaven_repository_structure_and
>>>
>>>
>>
>> I wouldn't go veering off too far from the way Java Maven works as I
>> won't be too keen on integrating this back into the top-level project
>> being entirely different then the existing system. Using an entirely
>> different resolution mechanism  and a different local repository
>> format creating a dichotomy between Maven and NMaven.
>>
>> What do you tell people when they are accustom to Maven and then
>> start using NMaven and it works completely differently?
>>
>>> Shane
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Re: Repository Changes

[Jason van Zyl <ja...@maven.org>]

On 8 Aug 07, at 1:46 AM 8 Aug 07, Shane Isbell wrote:

> I'll tell them it works ;)
>

No arguments that the existing artifact code leaves some to be  
desired, but once it's separated, cleaned up, switch to being graph  
based, and adjust the api and support classes so that different  
implementations like Ivy, OSGi, and Maven are possible it will be  
fine. Ultimately I see repositories being managed by applications and  
that will become the norm, for required functionality and  
transactionality so the storage formats won't be visible. But on the  
local side what the user actually sees being entirely different  
concerns me.

> On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>>
>> On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:
>>
>>> Some background info on the repository changes:
>>>
>>> http://www.jroller.com/random7/entry/
>>> apache_nmaven_repository_structure_and
>>>
>>>
>>
>> I wouldn't go veering off too far from the way Java Maven works as I
>> won't be too keen on integrating this back into the top-level project
>> being entirely different then the existing system. Using an entirely
>> different resolution mechanism  and a different local repository
>> format creating a dichotomy between Maven and NMaven.
>>
>> What do you tell people when they are accustom to Maven and then
>> start using NMaven and it works completely differently?
>>
>>> Shane
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder and PMC Chair, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>>
>>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Re: Repository Changes

[Shane Isbell <sh...@gmail.com>]

I'll tell them it works ;)

On 8/7/07, Jason van Zyl <ja...@maven.org> wrote:
>
>
> On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:
>
> > Some background info on the repository changes:
> >
> > http://www.jroller.com/random7/entry/
> > apache_nmaven_repository_structure_and
> >
> >
>
> I wouldn't go veering off too far from the way Java Maven works as I
> won't be too keen on integrating this back into the top-level project
> being entirely different then the existing system. Using an entirely
> different resolution mechanism  and a different local repository
> format creating a dichotomy between Maven and NMaven.
>
> What do you tell people when they are accustom to Maven and then
> start using NMaven and it works completely differently?
>
> > Shane
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>

Re: Repository Changes

[Jason van Zyl <ja...@maven.org>]

On 8 Aug 07, at 12:40 AM 8 Aug 07, Shane Isbell wrote:

> Some background info on the repository changes:
>
> http://www.jroller.com/random7/entry/ 
> apache_nmaven_repository_structure_and
>
>

I wouldn't go veering off too far from the way Java Maven works as I  
won't be too keen on integrating this back into the top-level project  
being entirely different then the existing system. Using an entirely  
different resolution mechanism  and a different local repository  
format creating a dichotomy between Maven and NMaven.

What do you tell people when they are accustom to Maven and then  
start using NMaven and it works completely differently?

> Shane

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------