Re: Maven jar manifests

[Jonathan Costers <jo...@googlemail.com>]

Around classdepandjar, I remember what the "issue" was I had.

>From README.txt bundled with classdepandjar source code:

"This release of ClassDepAndJarTask contains classes from the latest version
(Alpha2) of the BuildTool project. If you rebuild ClassDepAndJarTask, then
you must have this version of the BuildTool in the classpath. See
build.xml."

I don't seem to find source code nor binaries for the BuildTool project
anymore.
However, I may still have that code from back in the days. I remember I
burnt this nice CD to go with my master's thesis, containing all the Jini
goodies existing at the time (2001). I'll try and dig that up too...

2010/5/27 Peter Firmstone <ji...@zeus.net.au>

> Thanks Jonathan, anything you can do is much appreciated.
>
> Cheers,
>
> Peter.
>
> Jonathan Costers wrote:
>
>>
>> I was working on the maven artifacts a while ago, and have that work still
>> available in my (outdated) workspace.
>> When I find some time (difficult lately) I'll contribute what I have.
>> I remember I was able to build Maven artifacts for just about any River
>> JAR.
>>
>>  I have raised the same concern earlier.
>> The Class-Path mechanism conflicts with a number of things, including
>> Maven
>> ...
>>
>>  Similarly, I was working on integrating that piece of code into the River
>> codebase before.
>> However there was some problem with it. I'll (again) dig into my workspace
>> and get more details.
>>
>>
>>
>>>  3) To what degree would a further restructuring of the code be of
>>>
>>>
>>>> interest? I don't necessarily have specific ideas here (yet), but it
>>>> seems like we're finally free to begin to move things around in a way
>>>> that would serve the project's goals and it would be good to have the
>>>> conversation first.
>>>>
>>>>
>>>>
>>>>
>>> Is it going to make the codebase easier to maintain?  If your talking
>>> about
>>> making the platform more modular, eg, each platform service could be it's
>>> own subproject or something like that, provided we can provide a
>>> migration
>>> path for existing Jini 2.1 users then that has to be a plus.   I've
>>> thought
>>> about this sort of modularisation and for those not wanting to do
>>> separate
>>> downloads for components, we can distribute a complete zip artifact.  I
>>> think if your considering ease of development and improving the
>>> application
>>> development experience then I'm all for it.  I think net.jini.* has to be
>>> evolved with backward compatibility in mind, however com.sun.* is your
>>> oyster.
>>>
>>>
>>>
>>>
>> Completely agree. Some form of restructuring/modularization has been
>> preformed already, but there is certainly room for more of the same.
>>
>>
>>
>
>