river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Costers <jonathan.cost...@googlemail.com>
Subject Re: Maven jar manifests
Date Wed, 26 May 2010 15:57:46 GMT
2010/5/25 Peter Firmstone <jini@zeus.net.au>

> Jeff Ramsdale wrote:
>
>> I provided some poms awhile back that were checked in, but there were
>> some very reasonable questions raised about how (in particular) dl
>> jars should be treated in Maven. See:
>> https://issues.apache.org/jira/browse/RIVER-317
>>
>> At the time there didn't seem to be a definitive answer with respect
>> to Apache River. Now that the conversation around Maven and River is
>> occurring I think we'll see something emerge. If so, and if it might
>> be the preferable way to write River services, shouldn't River itself
>> be built with Maven? Either way I'd be glad to help but I'm about to
>> leave for vacation for a week. Meanwhile the conversation can continue
>> and I'll attempt to monitor...
>>
>> If converting the build to Maven is of interest (and I'd recommend it)
>> there are a few issues I'd raise.
>>
>>
>
> It needs someone willing to do it, I'm not in a position to make a
> judgement, I don't have maven experience, I'm certainly not about to knock
> back contributions or offers of help, if someone has the experience and is
> willing to follow though, I'm happy to learn.  I'd take on a small project
> conversion to maven myself and learn, but not something the size of River
> straight up.
>
>
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.


>
>  1) Is there an issue with Jini's use of the Class-Path jar manifest
>> headers in the context of Maven? That is, is the Class-Path header
>> used in a number of the jars just a hint or does it have security
>> implications or some-such? The reason I ask is depending on how Maven
>> is used it could be possible to build a classpath from a Maven
>> repository in which jars are not positioned in the filesystem relative
>> to each other in a way that is reflected in the jars' manifests. For
>> instance, a service container could choose to build a runtime
>> classpath (including core Jini/River jars) directly from a local Maven
>> repo and the structure of the Maven repo would not match the jar
>> manifests as currently built.
>>
>>
>
> I don't know, does someone on the list have the answer?
>
>
I have raised the same concern earlier.
The Class-Path mechanism conflicts with a number of things, including Maven
...



>  2) As Dennis mentioned on another thread, should classdepandjar (
>> https://classdepandjar.dev.java.net/ ) be used? Should it be converted
>> to Maven? Chris Sterling did something similar with the Maven Classdep
>> Plugin ( https://maven-classdep-plugin.dev.java.net/ ) but I don't
>> know if it ever functioned 100%. If there's interest I could contact
>> him to revive it (he's a friend) or, alternatively, River could
>> provide its own Maven plugin (perhaps in conjunction with the
>> Archetype(s) Dennis suggested). In any case, whatever solution is
>> selected should definitely use the updated Classdep that doesn't
>> depend on Sun's tools.jar. I see that as a prerequisite for everything
>> else.
>>
>>
> Wow, I didn't even know this existed, definitely get in touch see if Chris
> is happy to donate the code, we can look at both, lets see what we can
> learn.
>
>
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.


> I tend to treat everything like an experiment, I'm free to change my mind
> if something's not working out or if someone's got a better suggestion,
> doing that instead.  I think many people have fears about what might happen,
> however that leads to paralysis, so we're better of trying something,
> learning, then trying again.  Usually people want to change something
> because there's an underlying issue, we need to identify that issue and
> weigh up the solution as it develops.  What you conceive in the beginning
> and what you end up with are always different anyway.
>
> Cheers,
>
> Peter.
>
>  -jeff
>>
>> On Mon, May 24, 2010 at 9:14 PM, Peter Firmstone <jini@zeus.net.au>
>> wrote:
>>
>>
>>> Do we have someone willing to create some ant scripts to build the Maven
>>> Manifests for River's jar files?
>>>
>>>
>>>
>>>
>>
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message