You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/05/25 06:14:05 UTC
Maven jar manifests
Do we have someone willing to create some ant scripts to build the Maven
Manifests for River's jar files?
Re: Maven jar manifests
Posted by Jonathan Costers <jo...@googlemail.com>.
I just stumbled on this target in build.xml:
<!-- TODO cleanup and find out where exactly to publish to -->
<!-- Note that you need the Maven Ant tasks (
http://maven.apache.org/ant-tasks/)
installed to use this task -->
<target name="deploy-artifacts" depends="jars">
<!--<artifact:install-provider artifactId="wagon-file"
version="1.0-beta-2"/>
<artifact:install-provider artifactId="wagon-http"
version="1.0-beta-2"/>
<artifact:install-provider artifactId="wagon-ssh"
version="1.0-beta-2"/>-->
<!-- Override this in <river src distr. home>/build.properties to
try out -->
<property name="m2.repository" value="file:///home/jonathan/maven"
/>
<macrodef name="deploy">
<attribute name="file" />
<attribute name="pom" />
<sequential>
<artifact:deploy file="@{file}" >
<remoteRepository url="${m2.repository}"/>
<pom refid="@{pom}"/>
</artifact:deploy>
</sequential>
</macrodef>
<artifact:pom id="parent" file="${poms.dir}/pom.xml" />
<artifact:pom id="jini-core" file="${poms.dir}/jini-core/pom.xml" />
<artifact:pom id="jini-ext" file="${poms.dir}/jini-ext/pom.xml" />
<artifact:pom id="jsk-lib" file="${poms.dir}/jsk-lib/pom.xml" />
<artifact:pom id="jsk-dl" file="${poms.dir}/jsk-dl/pom.xml" />
<artifact:pom id="jsk-resources"
file="${poms.dir}/jsk-resources/pom.xml" />
<artifact:pom id="jsk-platform"
file="${poms.dir}/jsk-platform/pom.xml" />
<artifact:pom id="jsk-policy" file="${poms.dir}/jsk-policy/pom.xml"
/>
<artifact:pom id="serviceui" file="${poms.dir}/serviceui/pom.xml" />
<artifact:pom id="sun-util" file="${poms.dir}/sun-util/pom.xml" />
<artifact:pom id="start" file="${poms.dir}/start/pom.xml" />
<artifact:pom id="tools" file="${poms.dir}/tools/pom.xml" />
<deploy file="${lib.dir}/jini-core.jar" pom="jini-core" />
<deploy file="${lib.dir}/jini-ext.jar" pom="jini-ext" />
<deploy file="${lib.dir}/jsk-lib.jar" pom="jsk-lib" />
<deploy file="${lib-dl.dir}/jsk-dl.jar" pom="jsk-dl" />
<deploy file="${lib.dir}/jsk-resources.jar" pom="jsk-resources" />
<deploy file="${lib.dir}/jsk-platform.jar" pom="jsk-platform" />
<deploy file="${lib-ext.dir}/jsk-policy.jar" pom="jsk-policy" />
<deploy file="${lib.dir}/serviceui.jar" pom="serviceui" />
<deploy file="${lib.dir}/sun-util.jar" pom="sun-util" />
<deploy file="${lib.dir}/start.jar" pom="start" />
<deploy file="${lib.dir}/tools.jar" pom="tools" />
</target>
So looks like I committed this after all... Sorry.
This was only a rudimentary start though, only containing some of the River
JARs.
I remember that I successfully tried this with a local Maven repository.
Not sure what Maven repository to publish to? (i.e. when Hudson builds, what
repository should it publish the artifacts to?)
2010/5/25 Peter Firmstone <ji...@zeus.net.au>
> Do we have someone willing to create some ant scripts to build the Maven
> Manifests for River's jar files?
>
>
Re: Maven jar manifests
Posted by 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.
>>
>>
>>
>
>
Re: Maven jar manifests
Posted by 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.
>
>
Re: Maven jar manifests
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/5/25 Peter Firmstone <ji...@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 <ji...@zeus.net.au>
>> wrote:
>>
>>
>>> Do we have someone willing to create some ant scripts to build the Maven
>>> Manifests for River's jar files?
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: Maven jar manifests
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/5/25 Christopher Dolan <ch...@avid.com>
> I strongly agree. Manifest Class-Paths have always caused problems for
> my team in the context of Jini/River codebases. Furthermore, Eclipse
> doesn't handle them very well (getting better in 3.5, but still broken).
>
Exactly. There's all sorts of headaches with Class-Path.
> Chris
>
> -----Original Message-----
> From: Gregg Wonderly [mailto:gregg@wonderly.org]
> Sent: Tuesday, May 25, 2010 4:02 PM
> To: river-dev@incubator.apache.org
> Subject: Re: Maven jar manifests
>
> Dennis Reedy wrote:
> > On May 25, 2010, at 634AM, Peter Firmstone wrote:
> >> Jeff Ramsdale wrote:
> >>> 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 would suggest that we advise that embedded Class-Path manifest
> > headers not be used, and the resolution of a jar's dependencies are
> > based on the declared dependencies in the pom.
>
> The Class-Path manifest feels convenient when you are running stuff out
> of jars
> (java -jar) and doing things simple enough that a startup
> script/modularization
> is not needed. But, as soon as you start deploying things into an
> environment
> where there are varied components in different places, things start to
> get messy.
>
> For example, netbeans puts all of your dependent jars into dist/lib with
> your
> jar being in dist. This seems convenient enough. But wait until you
> have A.jar
> -> B.jar -> C.jar and A.jar -> D.jar -> B.jar. Then, you suddenly have
>
> A.jar
> lib/B.jar
> lib/lib/C.jar
> lib/D.jar
> lib/lib/B.jar
>
> being referenced by the codebase class loading. And it can get worse.
> So, it
> makes a lot of sense to just not use Class-Path, and compose the
> appropriate
> URLClassLoader/PreferredClassLoader URLs as part of the deployment
> packaging
> step so that you can account for where each jar will actually be sourced
> from,
> including the difference between somethings coming from maven and others
> coming
> from a web server etc.
>
> Gregg Wonderly
>
Re: Maven jar manifests
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/5/26 Dennis Reedy <de...@gmail.com>
>
> On May 26, 2010, at 131AM, Peter Firmstone wrote:
>
> > Do we need to replace them? What with?
>
> The classpath that results from the resolution of the artifact based on the
> declarations in the pom.
>
Agreed.
Re: Maven jar manifests
Posted by Dennis Reedy <de...@gmail.com>.
On May 26, 2010, at 131AM, Peter Firmstone wrote:
> Do we need to replace them? What with?
The classpath that results from the resolution of the artifact based on the declarations in the pom.
Re: Maven jar manifests
Posted by Peter Firmstone <ji...@zeus.net.au>.
Do we need to replace them? What with? Sounds like their use should be
strongly discouraged.
Peter.
Christopher Dolan wrote:
> I strongly agree. Manifest Class-Paths have always caused problems for
> my team in the context of Jini/River codebases. Furthermore, Eclipse
> doesn't handle them very well (getting better in 3.5, but still broken).
>
> Chris
>
> -----Original Message-----
> From: Gregg Wonderly [mailto:gregg@wonderly.org]
> Sent: Tuesday, May 25, 2010 4:02 PM
> To: river-dev@incubator.apache.org
> Subject: Re: Maven jar manifests
>
> Dennis Reedy wrote:
>
>> On May 25, 2010, at 634AM, Peter Firmstone wrote:
>>
>>> Jeff Ramsdale wrote:
>>>
>>>> 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 would suggest that we advise that embedded Class-Path manifest
>>
> > headers not be used, and the resolution of a jar's dependencies are
> > based on the declared dependencies in the pom.
>
> The Class-Path manifest feels convenient when you are running stuff out
> of jars
> (java -jar) and doing things simple enough that a startup
> script/modularization
> is not needed. But, as soon as you start deploying things into an
> environment
> where there are varied components in different places, things start to
> get messy.
>
> For example, netbeans puts all of your dependent jars into dist/lib with
> your
> jar being in dist. This seems convenient enough. But wait until you
> have A.jar
> -> B.jar -> C.jar and A.jar -> D.jar -> B.jar. Then, you suddenly have
>
> A.jar
> lib/B.jar
> lib/lib/C.jar
> lib/D.jar
> lib/lib/B.jar
>
> being referenced by the codebase class loading. And it can get worse.
> So, it
> makes a lot of sense to just not use Class-Path, and compose the
> appropriate
> URLClassLoader/PreferredClassLoader URLs as part of the deployment
> packaging
> step so that you can account for where each jar will actually be sourced
> from,
> including the difference between somethings coming from maven and others
> coming
> from a web server etc.
>
> Gregg Wonderly
>
>
RE: Maven jar manifests
Posted by Christopher Dolan <ch...@avid.com>.
I strongly agree. Manifest Class-Paths have always caused problems for
my team in the context of Jini/River codebases. Furthermore, Eclipse
doesn't handle them very well (getting better in 3.5, but still broken).
Chris
-----Original Message-----
From: Gregg Wonderly [mailto:gregg@wonderly.org]
Sent: Tuesday, May 25, 2010 4:02 PM
To: river-dev@incubator.apache.org
Subject: Re: Maven jar manifests
Dennis Reedy wrote:
> On May 25, 2010, at 634AM, Peter Firmstone wrote:
>> Jeff Ramsdale wrote:
>>> 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 would suggest that we advise that embedded Class-Path manifest
> headers not be used, and the resolution of a jar's dependencies are
> based on the declared dependencies in the pom.
The Class-Path manifest feels convenient when you are running stuff out
of jars
(java -jar) and doing things simple enough that a startup
script/modularization
is not needed. But, as soon as you start deploying things into an
environment
where there are varied components in different places, things start to
get messy.
For example, netbeans puts all of your dependent jars into dist/lib with
your
jar being in dist. This seems convenient enough. But wait until you
have A.jar
-> B.jar -> C.jar and A.jar -> D.jar -> B.jar. Then, you suddenly have
A.jar
lib/B.jar
lib/lib/C.jar
lib/D.jar
lib/lib/B.jar
being referenced by the codebase class loading. And it can get worse.
So, it
makes a lot of sense to just not use Class-Path, and compose the
appropriate
URLClassLoader/PreferredClassLoader URLs as part of the deployment
packaging
step so that you can account for where each jar will actually be sourced
from,
including the difference between somethings coming from maven and others
coming
from a web server etc.
Gregg Wonderly
Re: Maven jar manifests
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
> On May 25, 2010, at 634AM, Peter Firmstone wrote:
>> Jeff Ramsdale wrote:
>>> 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 would suggest that we advise that embedded Class-Path manifest
> headers not be used, and the resolution of a jar's dependencies are
> based on the declared dependencies in the pom.
The Class-Path manifest feels convenient when you are running stuff out of jars
(java -jar) and doing things simple enough that a startup script/modularization
is not needed. But, as soon as you start deploying things into an environment
where there are varied components in different places, things start to get messy.
For example, netbeans puts all of your dependent jars into dist/lib with your
jar being in dist. This seems convenient enough. But wait until you have A.jar
-> B.jar -> C.jar and A.jar -> D.jar -> B.jar. Then, you suddenly have
A.jar
lib/B.jar
lib/lib/C.jar
lib/D.jar
lib/lib/B.jar
being referenced by the codebase class loading. And it can get worse. So, it
makes a lot of sense to just not use Class-Path, and compose the appropriate
URLClassLoader/PreferredClassLoader URLs as part of the deployment packaging
step so that you can account for where each jar will actually be sourced from,
including the difference between somethings coming from maven and others coming
from a web server etc.
Gregg Wonderly
Re: Maven jar manifests
Posted by Dennis Reedy <de...@gmail.com>.
On May 25, 2010, at 634AM, Peter Firmstone wrote:
> 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.
>
>> 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 would suggest that we advise that embedded Class-Path manifest headers not be used, and the resolution of a jar's dependencies are based on the declared dependencies in the pom.
>
>> 2) As Dennis mentioned on another thread, should classdepandjar (
>> https://classdepandjar.dev.java.net/ ) be used? Should it be converted
>> to Maven?
Thats already been done with the Rio plugin (http://www.rio-project.org/classdepandjar-mojo.html), I thought you were using it? :) River is most welcome to it if the project would like it.
>> 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.
Is the refactored ClassDep released?
>>
> 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.
>
>> 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.
The maven project restructuring would indeed allow each service to be a sub-module. Unless we choose to change the names of the produced artifacts to align themselves with the newly discussed conventions, I dont see issues with backwards compatibility, because the contents of the jars would be the same.
I would also suggest that if you go down this route, you would want to move from the com.sun.jini namespace to the org.apache.river namespace.
A big (and lingering) question to me is how to integrate the current test framework into a maven project, or to do it at all.
Re: Maven jar manifests
Posted by Peter Firmstone <ji...@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.
> 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?
> 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.
> 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.
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 <ji...@zeus.net.au> wrote:
>
>> Do we have someone willing to create some ant scripts to build the Maven
>> Manifests for River's jar files?
>>
>>
>>
>
>
Re: Maven jar manifests
Posted by Jeff Ramsdale <je...@gmail.com>.
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.
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.
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.
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.
-jeff
On Mon, May 24, 2010 at 9:14 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Do we have someone willing to create some ant scripts to build the Maven
> Manifests for River's jar files?
>
>