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 2009/09/30 08:48:15 UTC
Maven Artefacts RIVER-317 - AR2 Release
Anyone have any ideas or willing to assist with patches? It'd be nice
to have this complete for AR2.
Cheers,
Peter.
Dennis Reedy (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243 ]
>
> Dennis Reedy commented on RIVER-317:
> ------------------------------------
>
> I dont see how the -dl.jar files are being handled with this approach. How will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined? With River services we have multiple artifacts per service, an implementation jar, a download (client) jar and potentially a service ui jar.
>
> I suggest that we need to be thinking of adding classifiers for the artifacts, allowing dependencies to be resolved correctly. For example, if I am using Outrigger, I need to be able to start Outrigger using outrigger.jar and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to only have outigger-dl.jar in it's classpath not outrigger.jar.
>
> Declaring dependencies on River produced maven artifacts need to account for how a maven project will use the artifacts.
>
>
>> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
>> -------------------------------------------------------------------------------
>>
>> Key: RIVER-317
>> URL: https://issues.apache.org/jira/browse/RIVER-317
>> Project: River
>> Issue Type: Task
>> Components: Web site and infrastructure
>> Affects Versions: AR2, AR3
>> Reporter: Jeff Ramsdale
>> Fix For: AR2
>>
>> Attachments: river-poms.patch
>>
>>
>> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
>> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>
>
>
Packaging and deployment issues
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg, you wanted to open a discussion on Packaging and Deployment
issues, perhaps this should be raised as an issue on JIRA?
Its quite a complex issue, I'm not surprised it didn't garner much
response for that reason, however it is an issue that will need to be
dealt with sooner or later. I certainly don't know the solution,
however if we can work out what the constraints are, the pros and cons
and possible returns / benefits for each we might be able to address the
issue?
Cheers,
Peter.
Gregg Wonderly wrote:
> Dennis Reedy wrote:
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but
>> as it relates to Maven created service artifacts I am not so sure.
>
> I am not trying to focus this issue on solving anything related to
> maven. Instead, I am trying to discover what people think about
> creating an archive structure that could then be used for service
> deployment into various environments. Clearly, we could provide an
> archive assembler that used maven for managing the content of what was
> placed in the archive.
>
> The generation of the archive is one issue. But, on the other end is
> the consumption, and that's where I'd like to initially focus the
> discussion. I think that if we feel like it is something that the
> containers and deployment environments could use, and benefit from,
> than we can talk about providing such archives as a maven component
> from the river build.
>
> I'd like to discuss deployment issues regarding packaging, managing
> various pieces of a service deployment in particular environments, and
> solutions people have put together to see if there really is a place
> for such a thing, or if I'm just barking up the wrong tree.
>
> Gregg Wonderly
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Dennis Reedy <de...@gmail.com>.
On Oct 1, 2009, at 307PM, Gregg Wonderly wrote:
> Dennis Reedy wrote:
>> Hi Gregg,
>> To a certain extent I think having an archive would make sense, but
>> as it relates to Maven created service artifacts I am not so sure.
>
> I am not trying to focus this issue on solving anything related to
> maven.
Okay, perhaps I assumed your response had something to do with Maven
since was part of this thread. FWIW, I suggest you break it out of
this thread and start a new topic.
Re: Service Archive Structure (was: RE: Maven Artefacts RIVER-317 -
AR2 Release)
Posted by Patrick Wright <pd...@gmail.com>.
Hi
I also think this is a good direction to go in, and would benefit from
group discussion (and action :)).
Personally, I think it would help if we focused on a handful for
specific, widely-applicable use cases/deployment targets. What I mean
is that for example, in my work environment it's hard to get people to
accept a new type of service container or service container model. But
if I say, this service can be packaged as a WAR, or it's just a Java
app that can be started on its own (e.g. with Java Service Wrapper),
then they will go along with it. I think there is a target "market"
for service-oriented/distributed apps which rely on mainstream Java
container/server technologies. That won't address all of the River
community's interests, but I believe this offers us the opportunity to
extend the community to those who would otherwise be considering
something like the Web Services stack or JEE.
I'm not saying that River as a whole needs to move in that direction,
but that it should driven by a sort of partner community/subproject. I
know from previous discussions on the mailing lists that there are
those that don't want to see Jini be pushed/promoted as just another
alternative to web services and JEE, and I agree that the vision and
capabilities of Jini include much more than that. But it is a market
which I, for example, ended up working in, and so I'd like to promote
that use-case. I also think that the previous community experiments
with one central Jini/JavaSpaces project and any number of external
projects doing their own thing hasn't worked out that well. Most, if
not all of the Jini-based service container/deployment projects are
run by one developer. I think only Rio has a sizable community in that
space. It would be better, IMO, if River had a sub-project for
container deployment, perhaps with a set of standards, e.g. around
annotations, configuration, and allowed/supported different
implementations. There is a lot of useful and usable code in the
various sister projects (Rio, Bantam, Seven, reef, etc.) which we
could use as a starting point.
Off the top of my head, some important goals/features would be
- Deployment to "standard" web containers, basically anything
supporting either basic Java web stack (servlet/JSP) or full JEE; this
would include servers like Tomcat, Glassfish, Jetty, Resin, etc.
Should work out of the box with a "standard" deployment package like a
WAR, EAR or SAR.
- LUS and codebase servers packaged for the same type of deployment
- Optional "simple server" startup outside of a container using Java
Service Wrapper (open source, cross-platform, includes watchdog
process, configurable, etc.) or equivalent
- Annotation-based "lightweight" service declaration--the whole JEE
and web services stacks are moving in this direction
- Automated DL JAR building either at compile time or at runtime
- Utilities (including command-line) to monitor lookup services,
health-check services for reachability, etc.
- Standard JMX beans to monitor and configure services
I'd add that it's important to provide a simple alternative to the
external Jini-specific config files. Something like Mayflower is one
direction to go in (since it integrates with Spring)--note that there
is a dependency injection API that will likely be approved for JDK 7
and which will allow dynamic configuration implemented by e.g. Spring,
Guice or others.
Last point, there has been a sea change in server-side app development
for Java servers in the last few years, driven in part by the success
of Ruby on Rails. All of the standard frameworks and APIs are going in
the direction of annotation-based configuration, convention over
configuration, and lightweight setup. This doesn't just impact the
initial out-of-the-box experience, but also the scenario where your
team decides, "we need to split this out to another service" and need
to do it quickly, e.g. in a matter of days or a couple of weeks, not
of months.
Hope this is all not off-topic for the thread.
Regards
Patrick
Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)
Posted by Tom Hobbs <to...@sucfin.com>.
I think there is a lot of merit in this idea. Creating a standard
".jsd" that described where to put which files (and therefore, which
files are needed) would make River service creation and deployment much
simpler.
One of my frustrations is the sprinkling of different discrete files and
bits and bobs that are all required to start up a service. Of course,
once you're used to what is needed it becomes second nature, but
developing that second nature is a pain. As is troubleshooting when
your second natures lets you down!
However, defining an archive file structure that describes everything
you need - and presumably ant tasks and the maven equivalents, to
generate and start/stop these things - will make life a whole lot
easier.
Where I work, we have a concept of a grouping of services which can all
be started together, often in the same JVM. Any given host can run
multiple "service groups". We developed our own directory structure
which describes where everything goes, new "service groups" then use a
template of that directory structure. The problem with this, though, is
that the scripts are all OS specific and need constant configuring and
maintaining. Also, hand rolling a "service group" directory is error
prone (although made simpler with some Bash magic).
If I understand Gregg (do I?) developing a way to package a service or
services could be left to some, River supplied, automated tool.
Starting them then becomes a simple process of;
$ java com.sun.jini.start.ServiceStarter MyService.jsd
Or something.
I also like the idea of making a mechanism of dropping these ".jsd"
files into other container environments. Dare I say "OSGi"? And have
them handle the starting/stopping of them.
River is great in that you can do a whole heap of really clever and
amazing things with it. But speaking as an "app developer" who just
wants to write services that will live solely within his own companies
secure and safe subnet, River/Jini can be an absolute pain.
Again, if I understand it right, these ".jsd" files would take away much
of that pain. Right?
Great idea, Gregg. In my opinion, this is well worth a Jira of its own
and some serious thought/effort put into it.
Cheers,
Tom
-----Original Message-----
From: Gregg Wonderly [mailto:gregg@wonderly.org]
Sent: 01 October 2009 20:08
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure.
I am not trying to focus this issue on solving anything related to
maven.
Instead, I am trying to discover what people think about creating an
archive
structure that could then be used for service deployment into various
environments. Clearly, we could provide an archive assembler that used
maven
for managing the content of what was placed in the archive.
The generation of the archive is one issue. But, on the other end is
the
consumption, and that's where I'd like to initially focus the
discussion. I
think that if we feel like it is something that the containers and
deployment
environments could use, and benefit from, than we can talk about
providing such
archives as a maven component from the river build.
I'd like to discuss deployment issues regarding packaging, managing
various
pieces of a service deployment in particular environments, and solutions
people
have put together to see if there really is a place for such a thing, or
if I'm
just barking up the wrong tree.
Gregg Wonderly
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure.
I am not trying to focus this issue on solving anything related to maven.
Instead, I am trying to discover what people think about creating an archive
structure that could then be used for service deployment into various
environments. Clearly, we could provide an archive assembler that used maven
for managing the content of what was placed in the archive.
The generation of the archive is one issue. But, on the other end is the
consumption, and that's where I'd like to initially focus the discussion. I
think that if we feel like it is something that the containers and deployment
environments could use, and benefit from, than we can talk about providing such
archives as a maven component from the river build.
I'd like to discuss deployment issues regarding packaging, managing various
pieces of a service deployment in particular environments, and solutions people
have put together to see if there really is a place for such a thing, or if I'm
just barking up the wrong tree.
Gregg Wonderly
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
Right .. I've read the releasing guidelines in the mean time.
My intentions with previous message was actually to induce a vote here :-)
I would just like this to move this forward (I think everybody does).
Sorry for giving maybe the wrong signals ...
2009/10/1 Niclas Hedhman <ni...@hedhman.org>
> Well, as you can see in the docs, "release" is a process of creating the
> artifacts for the community to test, review and the VOTE (that vote is
> starting should be announced to the Incubator PMC, i.e. general@ list)
> upon.
> Once successful vote here, a VOTE is also needed by the Incubator PMC.
>
> Not until that vote is successful are allowed to "publish" the release to
> the general public, such as download page on website or Maven repositories.
>
> Hope that clarifies the workflow a bit...
>
> -- Niclas
>
> On Oct 1, 2009 8:16 PM, "Jonathan Costers" <
> jonathan.costers@googlemail.com>
> wrote:
>
> I would definately NOT back out the POMs that were committed before. They
> are an excellent starting point for eventually publishing River artifacts
> to
> Maven repositories.
> Let's finish the discussion about the -dl JARs, but let's release first.
>
> If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
> the Ant build (when I get home tonight) and let Hudson pick it up.
> In about an hour after that we will have AR2 aka River 2.2.0.
>
> Getting AR2 out also means:
> - publishing the artifacts to the River web site
> - updating docs?
> - announcing it
>
> Thanks
> Jonathan
>
> 2009/10/1 Peter Firmstone <ji...@zeus.net.au>
>
> > By the sound of what Dennis is saying, it appears more to be a >
> classification issue rather than...
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Niclas Hedhman <ni...@hedhman.org>.
Well, as you can see in the docs, "release" is a process of creating the
artifacts for the community to test, review and the VOTE (that vote is
starting should be announced to the Incubator PMC, i.e. general@ list) upon.
Once successful vote here, a VOTE is also needed by the Incubator PMC.
Not until that vote is successful are allowed to "publish" the release to
the general public, such as download page on website or Maven repositories.
Hope that clarifies the workflow a bit...
-- Niclas
On Oct 1, 2009 8:16 PM, "Jonathan Costers" <jo...@googlemail.com>
wrote:
I would definately NOT back out the POMs that were committed before. They
are an excellent starting point for eventually publishing River artifacts to
Maven repositories.
Let's finish the discussion about the -dl JARs, but let's release first.
If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
the Ant build (when I get home tonight) and let Hudson pick it up.
In about an hour after that we will have AR2 aka River 2.2.0.
Getting AR2 out also means:
- publishing the artifacts to the River web site
- updating docs?
- announcing it
Thanks
Jonathan
2009/10/1 Peter Firmstone <ji...@zeus.net.au>
> By the sound of what Dennis is saying, it appears more to be a >
classification issue rather than...
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I would definately NOT back out the POMs that were committed before. They
are an excellent starting point for eventually publishing River artifacts to
Maven repositories.
Let's finish the discussion about the -dl JARs, but let's release first.
If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
the Ant build (when I get home tonight) and let Hudson pick it up.
In about an hour after that we will have AR2 aka River 2.2.0.
Getting AR2 out also means:
- publishing the artifacts to the River web site
- updating docs?
- announcing it
Thanks
Jonathan
2009/10/1 Peter Firmstone <ji...@zeus.net.au>
> By the sound of what Dennis is saying, it appears more to be a
> classification issue rather than an issue with the pom's themselves.
>
> I'd also like to thank you Jeff for your effort.
>
> Getting the artefacts out there also means that there'll be people using
> them, if there are issues, they'll be sorted sooner.
>
> Anyone have any last minute changes before we unleash (just kidding, I'm in
> a good mood), I mean release River?
>
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
>
> Cheers,
>
> Peter.
>
>
> Jim Waldo wrote:
>
>> I agree as well. Let's get something out.
>>
>> Jim
>>
>> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>>
>> Hi,
>>>
>>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
>>>
>>>> If the current poms do 50% (number chosen at random) of what we want
>>>> them to do,
>>>> then fine. My personal opinion is that it would be a bit demoralising
>>>> to back them
>>>> out because they're not "perfect" when we can include a valuable
>>>> contribution and
>>>> make them "perfect" in the next release.
>>>>
>>>
>>> +1 Incremental improvement is a key to success.
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>
>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Jeff Ramsdale wrote:
> Hey Peter,
>
> On Thu, Oct 1, 2009 at 4:41 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> By the sound of what Dennis is saying, it appears more to be a
>> classification issue rather than an issue with the pom's themselves.
>>
>
> Yes.
>
>
>> I'd also like to thank you Jeff for your effort.
>>
>
> Most welcome!
>
>
>> Getting the artefacts out there also means that there'll be people using
>> them, if there are issues, they'll be sorted sooner.
>>
>> Anyone have any last minute changes before we unleash (just kidding, I'm in
>> a good mood), I mean release River?
>>
>
> This shouldn't impact a River release, but I don't think the poms
> belong in the src dir--rather, they should probably be at the root of
> the project. When the src dir is designated a Java source directory in
> Eclipse it makes it hard to navigate the poms since it tries to turn
> their parent directory structure into packages. Additionally, their
> current location suggests they should be in the classpath, which is
> not the case.
>
Ok Thanks Jeff.
>
>> The world has waited long enough. Jukka, you still happy to assist with the
>> process?
>>
>> Cheers,
>>
>> Peter.
>>
>
> Thanks for the help, Peter!
>
> -jeff
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
Hey Peter,
On Thu, Oct 1, 2009 at 4:41 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> By the sound of what Dennis is saying, it appears more to be a
> classification issue rather than an issue with the pom's themselves.
Yes.
> I'd also like to thank you Jeff for your effort.
Most welcome!
> Getting the artefacts out there also means that there'll be people using
> them, if there are issues, they'll be sorted sooner.
>
> Anyone have any last minute changes before we unleash (just kidding, I'm in
> a good mood), I mean release River?
This shouldn't impact a River release, but I don't think the poms
belong in the src dir--rather, they should probably be at the root of
the project. When the src dir is designated a Java source directory in
Eclipse it makes it hard to navigate the poms since it tries to turn
their parent directory structure into packages. Additionally, their
current location suggests they should be in the classpath, which is
not the case.
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
>
> Cheers,
>
> Peter.
Thanks for the help, Peter!
-jeff
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok, Thanks Jukka.
Cheers,
Peter.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Oct 1, 2009 at 1:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> The world has waited long enough. Jukka, you still happy to assist with the
>> process?
>>
>
> Yes, though I'll be mostly offline on vacation next week. Before and
> after that I'll help the best I can.
>
> To get started, see [1] and the referenced documentation under [2] for
> lots of instructions related to the Apache release process. Note that
> some of the documentation may not apply to River and might even be
> contradictory. Use common sense or ask when something is not clear.
>
> [1] http://incubator.apache.org/guides/releasemanagement.html
> [2] http://www.apache.org/dev/
>
> BR,
>
> Jukka Zitting
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 1, 2009 at 1:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
Yes, though I'll be mostly offline on vacation next week. Before and
after that I'll help the best I can.
To get started, see [1] and the referenced documentation under [2] for
lots of instructions related to the Apache release process. Note that
some of the documentation may not apply to River and might even be
contradictory. Use common sense or ask when something is not clear.
[1] http://incubator.apache.org/guides/releasemanagement.html
[2] http://www.apache.org/dev/
BR,
Jukka Zitting
RE: Maven Artefacts RIVER-317 - AR2 Release
Posted by Tom Hobbs <to...@sucfin.com>.
> Anyone have any last minute changes before we unleash (just kidding,
I'm
> in a good mood), I mean release River?
Not me. No. None. Release release release! Go go go!
Sorry, just getting excited about the concept of having a new River
release.
Wow, silence from me for months and then three emails all in one day.
I'd better start pacing myself.
Tom
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: 01 October 2009 12:42
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
By the sound of what Dennis is saying, it appears more to be a
classification issue rather than an issue with the pom's themselves.
I'd also like to thank you Jeff for your effort.
Getting the artefacts out there also means that there'll be people using
them, if there are issues, they'll be sorted sooner.
Anyone have any last minute changes before we unleash (just kidding, I'm
in a good mood), I mean release River?
The world has waited long enough. Jukka, you still happy to assist with
the process?
Cheers,
Peter.
Jim Waldo wrote:
> I agree as well. Let's get something out.
>
> Jim
>
> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com>
wrote:
>>> If the current poms do 50% (number chosen at random) of what we want
>>> them to do,
>>> then fine. My personal opinion is that it would be a bit
>>> demoralising to back them
>>> out because they're not "perfect" when we can include a valuable
>>> contribution and
>>> make them "perfect" in the next release.
>>
>> +1 Incremental improvement is a key to success.
>>
>> BR,
>>
>> Jukka Zitting
>
>
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
By the sound of what Dennis is saying, it appears more to be a
classification issue rather than an issue with the pom's themselves.
I'd also like to thank you Jeff for your effort.
Getting the artefacts out there also means that there'll be people using
them, if there are issues, they'll be sorted sooner.
Anyone have any last minute changes before we unleash (just kidding, I'm
in a good mood), I mean release River?
The world has waited long enough. Jukka, you still happy to assist with
the process?
Cheers,
Peter.
Jim Waldo wrote:
> I agree as well. Let's get something out.
>
> Jim
>
> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
>>> If the current poms do 50% (number chosen at random) of what we want
>>> them to do,
>>> then fine. My personal opinion is that it would be a bit
>>> demoralising to back them
>>> out because they're not "perfect" when we can include a valuable
>>> contribution and
>>> make them "perfect" in the next release.
>>
>> +1 Incremental improvement is a key to success.
>>
>> BR,
>>
>> Jukka Zitting
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jim Waldo <Ji...@Sun.COM>.
I agree as well. Let's get something out.
Jim
On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
> Hi,
>
> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com>
> wrote:
>> If the current poms do 50% (number chosen at random) of what we
>> want them to do,
>> then fine. My personal opinion is that it would be a bit
>> demoralising to back them
>> out because they're not "perfect" when we can include a valuable
>> contribution and
>> make them "perfect" in the next release.
>
> +1 Incremental improvement is a key to success.
>
> BR,
>
> Jukka Zitting
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
> If the current poms do 50% (number chosen at random) of what we want them to do,
> then fine. My personal opinion is that it would be a bit demoralising to back them
> out because they're not "perfect" when we can include a valuable contribution and
> make them "perfect" in the next release.
+1 Incremental improvement is a key to success.
BR,
Jukka Zitting
RE: Maven Artefacts RIVER-317 - AR2 Release
Posted by Tom Hobbs <to...@sucfin.com>.
If the poms are documented as to what they do and don't do then let's include them as-is (or with any outstanding bits of quick tidy-up that they need).
Making the poms do exactly what we need/want them to do could easily be included in the next major/minor/point release we decide to release anyway - is that not the point of releasing new software versions? It also fits a bit better with the "release little, release often" mantra.
Again, as long as the AR2 (or 2.0.0 or whatever it's called), release notes include comments along the lines of "Included maven repositories to get this JAR and this JAR, but not that JAR or that JAR", we're covered.
If the current poms do 50% (number chosen at random) of what we want them to do, then fine. My personal opinion is that it would be a bit demoralising to back them out because they're not "perfect" when we can include a valuable contribution and make them "perfect" in the next release.
My opinion; however wrong it might be. :-)
Cheers,
Tom
-----Original Message-----
From: Jeff Ramsdale [mailto:jeff.ramsdale@gmail.com]
Sent: 01 October 2009 01:52
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
If the poms are holding up a release then by all means revert the
poms--there's nothing stopping us from retroactively deploying River
artifacts via Maven. I do think it would be a mistake, though, to cut
a separate release just for Maven artifacts. Maven is simply another
way to release the artifacts that have already been released. That's
why I initially imagined deploying 2.1.1 to Maven.
-jeff
On Wed, Sep 30, 2009 at 5:42 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> What sort of time frame are we looking at for an implementation?
>
> Unless this can be done in the very near future, how about we reverse Jeff's
> Maven Patch for now, release River 2.2.0, patch it back into trunk and aim
> for a River 2.2.1 release that includes support for Maven artefacts?
>
> I'd like to get River 2.2.0 out the door.
>
> P.S. Excellent discussion, great to see...
>
> Cheers,
>
> Peter.
>
> Dennis Reedy wrote:
>>
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but as it
>> relates to Maven created service artifacts I am not so sure. I am going
>> through a conversion of Rio to a maven project, and am actively working on
>> better maven integration as well, so alot of what I reference below is an
>> ongoing effort. That being said, I think a high level discussion coud put
>> things in a better context. Lets discuss how something like Outrigger would
>> pan out:
>>
>> Outrigger would have the following artifacts:
>>
>> org.apache.river:outrigger -> This would map to outrigger.jar
>> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar. The
>> key here is creating this artifact with a classifier. The classifier allows
>> us to distinguish artifacts that were built from the same POM but differ in
>> their content.
>>
>> So if I have the groupId:artifactId[:classifier] I can get the jars from
>> the local repository (and/or download them from a configured repository).
>> Once we have that, we should be able to deploy directly from the local Maven
>> repository, having the classpath and codebase resolved by dependency
>> management.
>>
>> IMO, this could provide seamless integration with created service
>> artifact(s), and perhaps mitigate against creating service archives.
>>
>> Dennis
>>
>>
>> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>>
>>> I am still of the opinion that we need to define a 'war' kind of archive
>>> of all the "jars" in a Jini service definition and make that the maven
>>> artifact (maybe use .jsd for the extension). Then, we need deployment tools
>>> that understand such a thing, and can open it and extract the bits out that
>>> are needed for each kind of use.
>>>
>>> I've thought about this some, and think that we could amend
>>> com.sun.jini.start to have another "config structure" that provided the
>>> appropriate details into the existing classes' construction inside of
>>> com.sun.jini.start.ServiceStarter.
>>>
>>> We might define the following '.jsd' file content from the top level
>>> directory perspective as a simple start.
>>>
>>> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
>>> depended on for class path.
>>> 2. META-INF/MANIFEST provides a code-base: entry that details the names
>>> of jars that must be in the codebase
>>> 3. codebase/* contains all the codebase jars which are part of the build
>>> 4. service/* contains all of the jars which are part of the classpath
>>> 5. java.policy would provide a default policy file
>>>
>>> The 1 and 2 items would be what containers used to decide how to package
>>> a service. They would take provided jars out of 3 and 4 to fill out the
>>> details as the primary source.
>>>
>>> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
>>> artifact names would be a something to use here would it not? We could use
>>> different MANIFEST entries to specify simple jars vs known, public maven
>>> artifact names.
>>>
>>> There could also be stuff in the MANIFEST about version etc to help
>>> containers decide what version of what is needed.
>>>
>>> These are the things I've thought a little bit about so far. I've been
>>> working on the start of a netbeans plugin to try and deal with testing and
>>> using Jini services inside of netbeans and providing the generation of a
>>> 'war' kind of thing. It's going fairly well so far, but real work keeps
>>> taking precedence. This defined 'packaging' would make such a plug-in
>>> container neutral. Containers would then just need to provide a
>>> "JiniServiceDeployer" implementing plug-in to allow new services to be
>>> deployed out of the IDE.
>>>
>>> What do the other container authors think about this. Would it be more
>>> work to do something like this without a real benefit, or is there something
>>> we can all gain by creating some standard packaging to help keep things
>>> together and allow service "owners" to create deployment packages more
>>> readily for public consumption in various kinds of container environments?
>>>
>>> Gregg Wonderly
>>>
>>> Jonathan Costers wrote:
>>>>
>>>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>>>> his suggestions and remarks.
>>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>>> Firmstone:
>>>>>
>>>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>>>> which I've added to the main trunk, however it isn't clear how the download
>>>>> files for service clients are handled, Dennis has made some suggestions,
>>>>> however I'm going to need some help with this.
>>>>>
>>>>> Feel free to check out and have a play.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Patrick Wright wrote:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>>> along are you in creating the POM(s) for the build system? What is
>>>>>> missing?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>>>> wrote:
>>>>>>
>>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>>> nice to
>>>>>>> have this complete for AR2.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>>
>>>>>>>> [
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>> ]
>>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>>> ------------------------------------
>>>>>>>>
>>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>>> approach. How
>>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>>> defined?
>>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>>> service ui
>>>>>>>> jar.
>>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>>> example, if I
>>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>>> outrigger.jar
>>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>>> needs to
>>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>>
>>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>>> account
>>>>>>>> for how a maven project will use the artifacts.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Deploy Apache River artifacts to Maven repositories (both release
>>>>>>>>> and
>>>>>>>>> snapshot)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: RIVER-317
>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>>> Project: River
>>>>>>>>> Issue Type: Task
>>>>>>>>> Components: Web site and infrastructure
>>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>>> Fix For: AR2
>>>>>>>>>
>>>>>>>>> Attachments: river-poms.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>>>> Maven
>>>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>>>> were
>>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>>> See thread:
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>
>
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
If the poms are holding up a release then by all means revert the
poms--there's nothing stopping us from retroactively deploying River
artifacts via Maven. I do think it would be a mistake, though, to cut
a separate release just for Maven artifacts. Maven is simply another
way to release the artifacts that have already been released. That's
why I initially imagined deploying 2.1.1 to Maven.
-jeff
On Wed, Sep 30, 2009 at 5:42 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> What sort of time frame are we looking at for an implementation?
>
> Unless this can be done in the very near future, how about we reverse Jeff's
> Maven Patch for now, release River 2.2.0, patch it back into trunk and aim
> for a River 2.2.1 release that includes support for Maven artefacts?
>
> I'd like to get River 2.2.0 out the door.
>
> P.S. Excellent discussion, great to see...
>
> Cheers,
>
> Peter.
>
> Dennis Reedy wrote:
>>
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but as it
>> relates to Maven created service artifacts I am not so sure. I am going
>> through a conversion of Rio to a maven project, and am actively working on
>> better maven integration as well, so alot of what I reference below is an
>> ongoing effort. That being said, I think a high level discussion coud put
>> things in a better context. Lets discuss how something like Outrigger would
>> pan out:
>>
>> Outrigger would have the following artifacts:
>>
>> org.apache.river:outrigger -> This would map to outrigger.jar
>> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar. The
>> key here is creating this artifact with a classifier. The classifier allows
>> us to distinguish artifacts that were built from the same POM but differ in
>> their content.
>>
>> So if I have the groupId:artifactId[:classifier] I can get the jars from
>> the local repository (and/or download them from a configured repository).
>> Once we have that, we should be able to deploy directly from the local Maven
>> repository, having the classpath and codebase resolved by dependency
>> management.
>>
>> IMO, this could provide seamless integration with created service
>> artifact(s), and perhaps mitigate against creating service archives.
>>
>> Dennis
>>
>>
>> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>>
>>> I am still of the opinion that we need to define a 'war' kind of archive
>>> of all the "jars" in a Jini service definition and make that the maven
>>> artifact (maybe use .jsd for the extension). Then, we need deployment tools
>>> that understand such a thing, and can open it and extract the bits out that
>>> are needed for each kind of use.
>>>
>>> I've thought about this some, and think that we could amend
>>> com.sun.jini.start to have another "config structure" that provided the
>>> appropriate details into the existing classes' construction inside of
>>> com.sun.jini.start.ServiceStarter.
>>>
>>> We might define the following '.jsd' file content from the top level
>>> directory perspective as a simple start.
>>>
>>> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
>>> depended on for class path.
>>> 2. META-INF/MANIFEST provides a code-base: entry that details the names
>>> of jars that must be in the codebase
>>> 3. codebase/* contains all the codebase jars which are part of the build
>>> 4. service/* contains all of the jars which are part of the classpath
>>> 5. java.policy would provide a default policy file
>>>
>>> The 1 and 2 items would be what containers used to decide how to package
>>> a service. They would take provided jars out of 3 and 4 to fill out the
>>> details as the primary source.
>>>
>>> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
>>> artifact names would be a something to use here would it not? We could use
>>> different MANIFEST entries to specify simple jars vs known, public maven
>>> artifact names.
>>>
>>> There could also be stuff in the MANIFEST about version etc to help
>>> containers decide what version of what is needed.
>>>
>>> These are the things I've thought a little bit about so far. I've been
>>> working on the start of a netbeans plugin to try and deal with testing and
>>> using Jini services inside of netbeans and providing the generation of a
>>> 'war' kind of thing. It's going fairly well so far, but real work keeps
>>> taking precedence. This defined 'packaging' would make such a plug-in
>>> container neutral. Containers would then just need to provide a
>>> "JiniServiceDeployer" implementing plug-in to allow new services to be
>>> deployed out of the IDE.
>>>
>>> What do the other container authors think about this. Would it be more
>>> work to do something like this without a real benefit, or is there something
>>> we can all gain by creating some standard packaging to help keep things
>>> together and allow service "owners" to create deployment packages more
>>> readily for public consumption in various kinds of container environments?
>>>
>>> Gregg Wonderly
>>>
>>> Jonathan Costers wrote:
>>>>
>>>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>>>> his suggestions and remarks.
>>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>>> Firmstone:
>>>>>
>>>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>>>> which I've added to the main trunk, however it isn't clear how the download
>>>>> files for service clients are handled, Dennis has made some suggestions,
>>>>> however I'm going to need some help with this.
>>>>>
>>>>> Feel free to check out and have a play.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Patrick Wright wrote:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>>> along are you in creating the POM(s) for the build system? What is
>>>>>> missing?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>>>> wrote:
>>>>>>
>>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>>> nice to
>>>>>>> have this complete for AR2.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>>
>>>>>>>> [
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>> ]
>>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>>> ------------------------------------
>>>>>>>>
>>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>>> approach. How
>>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>>> defined?
>>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>>> service ui
>>>>>>>> jar.
>>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>>> example, if I
>>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>>> outrigger.jar
>>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>>> needs to
>>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>>
>>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>>> account
>>>>>>>> for how a maven project will use the artifacts.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Deploy Apache River artifacts to Maven repositories (both release
>>>>>>>>> and
>>>>>>>>> snapshot)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: RIVER-317
>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>>> Project: River
>>>>>>>>> Issue Type: Task
>>>>>>>>> Components: Web site and infrastructure
>>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>>> Fix For: AR2
>>>>>>>>>
>>>>>>>>> Attachments: river-poms.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>>>> Maven
>>>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>>>> were
>>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>>> See thread:
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
What sort of time frame are we looking at for an implementation?
Unless this can be done in the very near future, how about we reverse
Jeff's Maven Patch for now, release River 2.2.0, patch it back into
trunk and aim for a River 2.2.1 release that includes support for Maven
artefacts?
I'd like to get River 2.2.0 out the door.
P.S. Excellent discussion, great to see...
Cheers,
Peter.
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure. I am
> going through a conversion of Rio to a maven project, and am actively
> working on better maven integration as well, so alot of what I
> reference below is an ongoing effort. That being said, I think a high
> level discussion coud put things in a better context. Lets discuss
> how something like Outrigger would pan out:
>
> Outrigger would have the following artifacts:
>
> org.apache.river:outrigger -> This would map to outrigger.jar
> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar.
> The key here is creating this artifact with a classifier. The
> classifier allows us to distinguish artifacts that were built from the
> same POM but differ in their content.
>
> So if I have the groupId:artifactId[:classifier] I can get the jars
> from the local repository (and/or download them from a configured
> repository). Once we have that, we should be able to deploy directly
> from the local Maven repository, having the classpath and codebase
> resolved by dependency management.
>
> IMO, this could provide seamless integration with created service
> artifact(s), and perhaps mitigate against creating service archives.
>
> Dennis
>
>
> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>
>> I am still of the opinion that we need to define a 'war' kind of
>> archive of all the "jars" in a Jini service definition and make that
>> the maven artifact (maybe use .jsd for the extension). Then, we need
>> deployment tools that understand such a thing, and can open it and
>> extract the bits out that are needed for each kind of use.
>>
>> I've thought about this some, and think that we could amend
>> com.sun.jini.start to have another "config structure" that provided
>> the appropriate details into the existing classes' construction
>> inside of com.sun.jini.start.ServiceStarter.
>>
>> We might define the following '.jsd' file content from the top level
>> directory perspective as a simple start.
>>
>> 1. META-INF/MANIFEST provides a class-path: entry that details the
>> jars depended on for class path.
>> 2. META-INF/MANIFEST provides a code-base: entry that details the
>> names of jars that must be in the codebase
>> 3. codebase/* contains all the codebase jars which are part of the
>> build
>> 4. service/* contains all of the jars which are part of the classpath
>> 5. java.policy would provide a default policy file
>>
>> The 1 and 2 items would be what containers used to decide how to
>> package a service. They would take provided jars out of 3 and 4 to
>> fill out the details as the primary source.
>>
>> Any missing jars from 3 and 4 would need to be obtained elsewhere.
>> Maven artifact names would be a something to use here would it not?
>> We could use different MANIFEST entries to specify simple jars vs
>> known, public maven artifact names.
>>
>> There could also be stuff in the MANIFEST about version etc to help
>> containers decide what version of what is needed.
>>
>> These are the things I've thought a little bit about so far. I've
>> been working on the start of a netbeans plugin to try and deal with
>> testing and using Jini services inside of netbeans and providing the
>> generation of a 'war' kind of thing. It's going fairly well so far,
>> but real work keeps taking precedence. This defined 'packaging' would
>> make such a plug-in container neutral. Containers would then just
>> need to provide a "JiniServiceDeployer" implementing plug-in to allow
>> new services to be deployed out of the IDE.
>>
>> What do the other container authors think about this. Would it be
>> more work to do something like this without a real benefit, or is
>> there something we can all gain by creating some standard packaging
>> to help keep things together and allow service "owners" to create
>> deployment packages more readily for public consumption in various
>> kinds of container environments?
>>
>> Gregg Wonderly
>>
>> Jonathan Costers wrote:
>>> Sorry, I actually need to thank Jeff for his contribution and Dennis
>>> for
>>> his suggestions and remarks.
>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>> Firmstone:
>>>> Jeff contributed a patch containing pom's for the River dist jar
>>>> files, which I've added to the main trunk, however it isn't clear
>>>> how the download files for service clients are handled, Dennis has
>>>> made some suggestions, however I'm going to need some help with this.
>>>>
>>>> Feel free to check out and have a play.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Peter.
>>>>
>>>> Patrick Wright wrote:
>>>>> Hi Peter
>>>>>
>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>> along are you in creating the POM(s) for the build system? What is
>>>>> missing?
>>>>>
>>>>>
>>>>> Thanks
>>>>> Patrick
>>>>>
>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone
>>>>> <ji...@zeus.net.au> wrote:
>>>>>
>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>> nice to
>>>>>> have this complete for AR2.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>
>>>>>>> [
>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>
>>>>>>> ]
>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>> approach. How
>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>> defined?
>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>> service ui
>>>>>>> jar.
>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>> example, if I
>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>> outrigger.jar
>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>> needs to
>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>
>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>> account
>>>>>>> for how a maven project will use the artifacts.
>>>>>>>
>>>>>>>
>>>>>>>> Deploy Apache River artifacts to Maven repositories (both
>>>>>>>> release and
>>>>>>>> snapshot)
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> Key: RIVER-317
>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>> Project: River
>>>>>>>> Issue Type: Task
>>>>>>>> Components: Web site and infrastructure
>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>> Fix For: AR2
>>>>>>>>
>>>>>>>> Attachments: river-poms.patch
>>>>>>>>
>>>>>>>>
>>>>>>>> It would be valuable if Apache River artifacts were deployed to
>>>>>>>> a Maven
>>>>>>>> repository upon release. It would be even better if snapshot
>>>>>>>> builds were
>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>> See thread:
>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Dennis Reedy <de...@gmail.com>.
Hi Gregg,
To a certain extent I think having an archive would make sense, but as
it relates to Maven created service artifacts I am not so sure. I am
going through a conversion of Rio to a maven project, and am actively
working on better maven integration as well, so alot of what I
reference below is an ongoing effort. That being said, I think a high
level discussion coud put things in a better context. Lets discuss
how something like Outrigger would pan out:
Outrigger would have the following artifacts:
org.apache.river:outrigger -> This would map to outrigger.jar
org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar.
The key here is creating this artifact with a classifier. The
classifier allows us to distinguish artifacts that were built from the
same POM but differ in their content.
So if I have the groupId:artifactId[:classifier] I can get the jars
from the local repository (and/or download them from a configured
repository). Once we have that, we should be able to deploy directly
from the local Maven repository, having the classpath and codebase
resolved by dependency management.
IMO, this could provide seamless integration with created service
artifact(s), and perhaps mitigate against creating service archives.
Dennis
On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
> I am still of the opinion that we need to define a 'war' kind of
> archive of all the "jars" in a Jini service definition and make that
> the maven artifact (maybe use .jsd for the extension). Then, we
> need deployment tools that understand such a thing, and can open it
> and extract the bits out that are needed for each kind of use.
>
> I've thought about this some, and think that we could amend
> com.sun.jini.start to have another "config structure" that provided
> the appropriate details into the existing classes' construction
> inside of com.sun.jini.start.ServiceStarter.
>
> We might define the following '.jsd' file content from the top level
> directory perspective as a simple start.
>
> 1. META-INF/MANIFEST provides a class-path: entry that details the
> jars depended on for class path.
> 2. META-INF/MANIFEST provides a code-base: entry that details the
> names of jars that must be in the codebase
> 3. codebase/* contains all the codebase jars which are part of the
> build
> 4. service/* contains all of the jars which are part of the classpath
> 5. java.policy would provide a default policy file
>
> The 1 and 2 items would be what containers used to decide how to
> package a service. They would take provided jars out of 3 and 4 to
> fill out the details as the primary source.
>
> Any missing jars from 3 and 4 would need to be obtained elsewhere.
> Maven artifact names would be a something to use here would it not?
> We could use different MANIFEST entries to specify simple jars vs
> known, public maven artifact names.
>
> There could also be stuff in the MANIFEST about version etc to help
> containers decide what version of what is needed.
>
> These are the things I've thought a little bit about so far. I've
> been working on the start of a netbeans plugin to try and deal with
> testing and using Jini services inside of netbeans and providing the
> generation of a 'war' kind of thing. It's going fairly well so far,
> but real work keeps taking precedence. This defined 'packaging'
> would make such a plug-in container neutral. Containers would then
> just need to provide a "JiniServiceDeployer" implementing plug-in to
> allow new services to be deployed out of the IDE.
>
> What do the other container authors think about this. Would it be
> more work to do something like this without a real benefit, or is
> there something we can all gain by creating some standard packaging
> to help keep things together and allow service "owners" to create
> deployment packages more readily for public consumption in various
> kinds of container environments?
>
> Gregg Wonderly
>
> Jonathan Costers wrote:
>> Sorry, I actually need to thank Jeff for his contribution and
>> Dennis for
>> his suggestions and remarks.
>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>> Firmstone:
>>> Jeff contributed a patch containing pom's for the River dist jar
>>> files, which I've added to the main trunk, however it isn't clear
>>> how the download files for service clients are handled, Dennis
>>> has made some suggestions, however I'm going to need some help
>>> with this.
>>>
>>> Feel free to check out and have a play.
>>>
>>> Thanks in advance,
>>>
>>> Peter.
>>>
>>> Patrick Wright wrote:
>>>> Hi Peter
>>>>
>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>> along are you in creating the POM(s) for the build system? What is
>>>> missing?
>>>>
>>>>
>>>> Thanks
>>>> Patrick
>>>>
>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone
>>>> <ji...@zeus.net.au> wrote:
>>>>
>>>>> Anyone have any ideas or willing to assist with patches? It'd
>>>>> be nice to
>>>>> have this complete for AR2.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Dennis Reedy (JIRA) wrote:
>>>>>
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>> ]
>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>> ------------------------------------
>>>>>>
>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>> approach. How
>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...)
>>>>>> be defined?
>>>>>> With River services we have multiple artifacts per service, an
>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>> service ui
>>>>>> jar.
>>>>>> I suggest that we need to be thinking of adding classifiers for
>>>>>> the
>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>> example, if I
>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>> outrigger.jar
>>>>>> and outrigger-dl.jar, but my client (the one who uses
>>>>>> Outrigger) needs to
>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>
>>>>>> Declaring dependencies on River produced maven artifacts need
>>>>>> to account
>>>>>> for how a maven project will use the artifacts.
>>>>>>
>>>>>>
>>>>>>> Deploy Apache River artifacts to Maven repositories (both
>>>>>>> release and
>>>>>>> snapshot)
>>>>>>>
>>>>>>> -------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: RIVER-317
>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>> Project: River
>>>>>>> Issue Type: Task
>>>>>>> Components: Web site and infrastructure
>>>>>>> Affects Versions: AR2, AR3
>>>>>>> Reporter: Jeff Ramsdale
>>>>>>> Fix For: AR2
>>>>>>>
>>>>>>> Attachments: river-poms.patch
>>>>>>>
>>>>>>>
>>>>>>> It would be valuable if Apache River artifacts were deployed
>>>>>>> to a Maven
>>>>>>> repository upon release. It would be even better if snapshot
>>>>>>> builds were
>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>> See thread:
>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox
>>>>>>> /<e2...@mail.gmail.com>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I am certainly not a container author .. But I find your thoughts very
interesting.
There has been discussion around deployment mechanisms before, IIRC (long
time ago)?
2009/10/1 Gregg Wonderly <gr...@wonderly.org>
> I am still of the opinion that we need to define a 'war' kind of archive of
> all the "jars" in a Jini service definition and make that the maven artifact
> (maybe use .jsd for the extension). Then, we need deployment tools that
> understand such a thing, and can open it and extract the bits out that are
> needed for each kind of use.
>
> I've thought about this some, and think that we could amend
> com.sun.jini.start to have another "config structure" that provided the
> appropriate details into the existing classes' construction inside of
> com.sun.jini.start.ServiceStarter.
>
> We might define the following '.jsd' file content from the top level
> directory perspective as a simple start.
>
> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
> depended on for class path.
> 2. META-INF/MANIFEST provides a code-base: entry that details the names of
> jars that must be in the codebase
> 3. codebase/* contains all the codebase jars which are part of the build
> 4. service/* contains all of the jars which are part of the classpath
> 5. java.policy would provide a default policy file
>
> The 1 and 2 items would be what containers used to decide how to package a
> service. They would take provided jars out of 3 and 4 to fill out the
> details as the primary source.
>
> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
> artifact names would be a something to use here would it not? We could use
> different MANIFEST entries to specify simple jars vs known, public maven
> artifact names.
>
> There could also be stuff in the MANIFEST about version etc to help
> containers decide what version of what is needed.
>
> These are the things I've thought a little bit about so far. I've been
> working on the start of a netbeans plugin to try and deal with testing and
> using Jini services inside of netbeans and providing the generation of a
> 'war' kind of thing. It's going fairly well so far, but real work keeps
> taking precedence. This defined 'packaging' would make such a plug-in
> container neutral. Containers would then just need to provide a
> "JiniServiceDeployer" implementing plug-in to allow new services to be
> deployed out of the IDE.
>
> What do the other container authors think about this. Would it be more
> work to do something like this without a real benefit, or is there something
> we can all gain by creating some standard packaging to help keep things
> together and allow service "owners" to create deployment packages more
> readily for public consumption in various kinds of container environments?
>
> Gregg Wonderly
>
>
> Jonathan Costers wrote:
>
>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>> his suggestions and remarks.
>>
>>
>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>> Firmstone:
>>
>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>> which I've added to the main trunk, however it isn't clear how the download
>>> files for service clients are handled, Dennis has made some suggestions,
>>> however I'm going to need some help with this.
>>>
>>> Feel free to check out and have a play.
>>>
>>> Thanks in advance,
>>>
>>> Peter.
>>>
>>> Patrick Wright wrote:
>>>
>>>> Hi Peter
>>>>
>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>> along are you in creating the POM(s) for the build system? What is
>>>> missing?
>>>>
>>>>
>>>> Thanks
>>>> Patrick
>>>>
>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>> wrote:
>>>>
>>>>
>>>>> Anyone have any ideas or willing to assist with patches? It'd be nice
>>>>> to
>>>>> have this complete for AR2.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Dennis Reedy (JIRA) wrote:
>>>>>
>>>>>
>>>>>> [
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>> ]
>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>> ------------------------------------
>>>>>>
>>>>>> I dont see how the -dl.jar files are being handled with this approach.
>>>>>> How
>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>> defined?
>>>>>> With River services we have multiple artifacts per service, an
>>>>>> implementation jar, a download (client) jar and potentially a service
>>>>>> ui
>>>>>> jar.
>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>> example, if I
>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>> outrigger.jar
>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs
>>>>>> to
>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>
>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>> account
>>>>>> for how a maven project will use the artifacts.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>>>>> snapshot)
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: RIVER-317
>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>> Project: River
>>>>>>> Issue Type: Task
>>>>>>> Components: Web site and infrastructure
>>>>>>> Affects Versions: AR2, AR3
>>>>>>> Reporter: Jeff Ramsdale
>>>>>>> Fix For: AR2
>>>>>>>
>>>>>>> Attachments: river-poms.patch
>>>>>>>
>>>>>>>
>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>> Maven
>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>> were
>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>> See thread:
>>>>>>>
>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/
>>>>>>> <e2...@mail.gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Gregg Wonderly <gr...@wonderly.org>.
I am still of the opinion that we need to define a 'war' kind of archive of all
the "jars" in a Jini service definition and make that the maven artifact (maybe
use .jsd for the extension). Then, we need deployment tools that understand
such a thing, and can open it and extract the bits out that are needed for each
kind of use.
I've thought about this some, and think that we could amend com.sun.jini.start
to have another "config structure" that provided the appropriate details into
the existing classes' construction inside of com.sun.jini.start.ServiceStarter.
We might define the following '.jsd' file content from the top level directory
perspective as a simple start.
1. META-INF/MANIFEST provides a class-path: entry that details the jars
depended on for class path.
2. META-INF/MANIFEST provides a code-base: entry that details the names of jars
that must be in the codebase
3. codebase/* contains all the codebase jars which are part of the build
4. service/* contains all of the jars which are part of the classpath
5. java.policy would provide a default policy file
The 1 and 2 items would be what containers used to decide how to package a
service. They would take provided jars out of 3 and 4 to fill out the details as
the primary source.
Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
artifact names would be a something to use here would it not? We could use
different MANIFEST entries to specify simple jars vs known, public maven
artifact names.
There could also be stuff in the MANIFEST about version etc to help containers
decide what version of what is needed.
These are the things I've thought a little bit about so far. I've been working
on the start of a netbeans plugin to try and deal with testing and using Jini
services inside of netbeans and providing the generation of a 'war' kind of
thing. It's going fairly well so far, but real work keeps taking precedence.
This defined 'packaging' would make such a plug-in container neutral.
Containers would then just need to provide a "JiniServiceDeployer" implementing
plug-in to allow new services to be deployed out of the IDE.
What do the other container authors think about this. Would it be more work to
do something like this without a real benefit, or is there something we can all
gain by creating some standard packaging to help keep things together and allow
service "owners" to create deployment packages more readily for public
consumption in various kinds of container environments?
Gregg Wonderly
Jonathan Costers wrote:
> Sorry, I actually need to thank Jeff for his contribution and Dennis for
> his suggestions and remarks.
>
>
> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
> Firmstone:
>> Jeff contributed a patch containing pom's for the River dist jar files,
>> which I've added to the main trunk, however it isn't clear how the
>> download files for service clients are handled, Dennis has made some
>> suggestions, however I'm going to need some help with this.
>>
>> Feel free to check out and have a play.
>>
>> Thanks in advance,
>>
>> Peter.
>>
>> Patrick Wright wrote:
>>> Hi Peter
>>>
>>> Can you update us on the status of River vis-a-vis Maven? How far
>>> along are you in creating the POM(s) for the build system? What is
>>> missing?
>>>
>>>
>>> Thanks
>>> Patrick
>>>
>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>>
>>>> Anyone have any ideas or willing to assist with patches? It'd be nice to
>>>> have this complete for AR2.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy (JIRA) wrote:
>>>>
>>>>> [
>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>> ]
>>>>> Dennis Reedy commented on RIVER-317:
>>>>> ------------------------------------
>>>>>
>>>>> I dont see how the -dl.jar files are being handled with this approach. How
>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>>>>> With River services we have multiple artifacts per service, an
>>>>> implementation jar, a download (client) jar and potentially a service ui
>>>>> jar.
>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>>>>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>
>>>>> Declaring dependencies on River produced maven artifacts need to account
>>>>> for how a maven project will use the artifacts.
>>>>>
>>>>>
>>>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>>>> snapshot)
>>>>>>
>>>>>> -------------------------------------------------------------------------------
>>>>>>
>>>>>> Key: RIVER-317
>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>> Project: River
>>>>>> Issue Type: Task
>>>>>> Components: Web site and infrastructure
>>>>>> Affects Versions: AR2, AR3
>>>>>> Reporter: Jeff Ramsdale
>>>>>> Fix For: AR2
>>>>>>
>>>>>> Attachments: river-poms.patch
>>>>>>
>>>>>>
>>>>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>>>>> repository upon release. It would be even better if snapshot builds were
>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>> See thread:
>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
Sorry, I actually need to thank Jeff for his contribution and Dennis for
his suggestions and remarks.
Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
Firmstone:
> Jeff contributed a patch containing pom's for the River dist jar files,
> which I've added to the main trunk, however it isn't clear how the
> download files for service clients are handled, Dennis has made some
> suggestions, however I'm going to need some help with this.
>
> Feel free to check out and have a play.
>
> Thanks in advance,
>
> Peter.
>
> Patrick Wright wrote:
> > Hi Peter
> >
> > Can you update us on the status of River vis-a-vis Maven? How far
> > along are you in creating the POM(s) for the build system? What is
> > missing?
> >
> >
> > Thanks
> > Patrick
> >
> > On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> >
> >> Anyone have any ideas or willing to assist with patches? It'd be nice to
> >> have this complete for AR2.
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >> Dennis Reedy (JIRA) wrote:
> >>
> >>> [
> >>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
> >>> ]
> >>> Dennis Reedy commented on RIVER-317:
> >>> ------------------------------------
> >>>
> >>> I dont see how the -dl.jar files are being handled with this approach. How
> >>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
> >>> With River services we have multiple artifacts per service, an
> >>> implementation jar, a download (client) jar and potentially a service ui
> >>> jar.
> >>> I suggest that we need to be thinking of adding classifiers for the
> >>> artifacts, allowing dependencies to be resolved correctly. For example, if I
> >>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
> >>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
> >>> only have outigger-dl.jar in it's classpath not outrigger.jar.
> >>>
> >>> Declaring dependencies on River produced maven artifacts need to account
> >>> for how a maven project will use the artifacts.
> >>>
> >>>
> >>>> Deploy Apache River artifacts to Maven repositories (both release and
> >>>> snapshot)
> >>>>
> >>>> -------------------------------------------------------------------------------
> >>>>
> >>>> Key: RIVER-317
> >>>> URL: https://issues.apache.org/jira/browse/RIVER-317
> >>>> Project: River
> >>>> Issue Type: Task
> >>>> Components: Web site and infrastructure
> >>>> Affects Versions: AR2, AR3
> >>>> Reporter: Jeff Ramsdale
> >>>> Fix For: AR2
> >>>>
> >>>> Attachments: river-poms.patch
> >>>>
> >>>>
> >>>> It would be valuable if Apache River artifacts were deployed to a Maven
> >>>> repository upon release. It would be even better if snapshot builds were
> >>>> also deployed to a snapshot repository by Hudson.
> >>>> See thread:
> >>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
I intended for the poms to correspond to the latest release at the
time they were contributed That is, I hoped the 2.1.1 release could be
deployed to the Maven repo since at the time I posted the poms AR2
wasn't in sight. I suppose if AR2 is released quickly it may not
matter that 2.1.1 isn't available in Maven. Also, I was targeting the
releases but since Hudson is now up again perhaps SNAPSHOT builds are
also a possibility.
BTW, are you able to provide source jars too? Would be great if we
could do a complete deployment...
I'm interested in whether the groupId/artifactId designations I gave
the artifacts are reasonable. Incidentally, I agree with Dennis that
the dl artifacts should be identified with classifiers, though I
hadn't had a chance to comment on that thread yet.
I'm going to kick off the version numbering as a separate topic.
-jeff
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I am investigating and experimenting using the contributed POMs (thanks
Dennis).
Currently, I have all artifacts deploying to a locally setup Maven
repository from the Ant build.xml, so that's good.
I have used the Maven Ant tasks - http://maven.apache.org/ant-tasks
Now the downside is this introduces a dependency on the Maven Ant tasks
JAR (Ant needs it in its classpath).
I believe the Ant instance Hudson uses to build has these tasks
installed, but I need to check to be sure.
Any thoughts on handling this dependency?
Another thing I would like to do is change the current version number of
the project to from 2.1.1 (which is actually incorrect, 2.1.1 was
released a long time ago) to 2.2-SNAPSHOT, to match the Maven artifact
version numbering (which makes a lot of sense anyway).
As soon as we decide to push out AR2, we can change this to 2.2.0?
Or should it be 2.2?
Comments on this?
Thanks
Jonathan
Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
Firmstone:
> Jeff contributed a patch containing pom's for the River dist jar files,
> which I've added to the main trunk, however it isn't clear how the
> download files for service clients are handled, Dennis has made some
> suggestions, however I'm going to need some help with this.
>
> Feel free to check out and have a play.
>
> Thanks in advance,
>
> Peter.
>
> Patrick Wright wrote:
> > Hi Peter
> >
> > Can you update us on the status of River vis-a-vis Maven? How far
> > along are you in creating the POM(s) for the build system? What is
> > missing?
> >
> >
> > Thanks
> > Patrick
> >
> > On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> >
> >> Anyone have any ideas or willing to assist with patches? It'd be nice to
> >> have this complete for AR2.
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >> Dennis Reedy (JIRA) wrote:
> >>
> >>> [
> >>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
> >>> ]
> >>> Dennis Reedy commented on RIVER-317:
> >>> ------------------------------------
> >>>
> >>> I dont see how the -dl.jar files are being handled with this approach. How
> >>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
> >>> With River services we have multiple artifacts per service, an
> >>> implementation jar, a download (client) jar and potentially a service ui
> >>> jar.
> >>> I suggest that we need to be thinking of adding classifiers for the
> >>> artifacts, allowing dependencies to be resolved correctly. For example, if I
> >>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
> >>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
> >>> only have outigger-dl.jar in it's classpath not outrigger.jar.
> >>>
> >>> Declaring dependencies on River produced maven artifacts need to account
> >>> for how a maven project will use the artifacts.
> >>>
> >>>
> >>>> Deploy Apache River artifacts to Maven repositories (both release and
> >>>> snapshot)
> >>>>
> >>>> -------------------------------------------------------------------------------
> >>>>
> >>>> Key: RIVER-317
> >>>> URL: https://issues.apache.org/jira/browse/RIVER-317
> >>>> Project: River
> >>>> Issue Type: Task
> >>>> Components: Web site and infrastructure
> >>>> Affects Versions: AR2, AR3
> >>>> Reporter: Jeff Ramsdale
> >>>> Fix For: AR2
> >>>>
> >>>> Attachments: river-poms.patch
> >>>>
> >>>>
> >>>> It would be valuable if Apache River artifacts were deployed to a Maven
> >>>> repository upon release. It would be even better if snapshot builds were
> >>>> also deployed to a snapshot repository by Hudson.
> >>>> See thread:
> >>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Jeff contributed a patch containing pom's for the River dist jar files,
which I've added to the main trunk, however it isn't clear how the
download files for service clients are handled, Dennis has made some
suggestions, however I'm going to need some help with this.
Feel free to check out and have a play.
Thanks in advance,
Peter.
Patrick Wright wrote:
> Hi Peter
>
> Can you update us on the status of River vis-a-vis Maven? How far
> along are you in creating the POM(s) for the build system? What is
> missing?
>
>
> Thanks
> Patrick
>
> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Anyone have any ideas or willing to assist with patches? It'd be nice to
>> have this complete for AR2.
>>
>> Cheers,
>>
>> Peter.
>>
>> Dennis Reedy (JIRA) wrote:
>>
>>> [
>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>> ]
>>> Dennis Reedy commented on RIVER-317:
>>> ------------------------------------
>>>
>>> I dont see how the -dl.jar files are being handled with this approach. How
>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>>> With River services we have multiple artifacts per service, an
>>> implementation jar, a download (client) jar and potentially a service ui
>>> jar.
>>> I suggest that we need to be thinking of adding classifiers for the
>>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>
>>> Declaring dependencies on River produced maven artifacts need to account
>>> for how a maven project will use the artifacts.
>>>
>>>
>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>> snapshot)
>>>>
>>>> -------------------------------------------------------------------------------
>>>>
>>>> Key: RIVER-317
>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>> Project: River
>>>> Issue Type: Task
>>>> Components: Web site and infrastructure
>>>> Affects Versions: AR2, AR3
>>>> Reporter: Jeff Ramsdale
>>>> Fix For: AR2
>>>>
>>>> Attachments: river-poms.patch
>>>>
>>>>
>>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>>> repository upon release. It would be even better if snapshot builds were
>>>> also deployed to a snapshot repository by Hudson.
>>>> See thread:
>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>
>>>>
>>>
>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Patrick Wright <pd...@gmail.com>.
Hi Peter
Can you update us on the status of River vis-a-vis Maven? How far
along are you in creating the POM(s) for the build system? What is
missing?
Thanks
Patrick
On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Anyone have any ideas or willing to assist with patches? It'd be nice to
> have this complete for AR2.
>
> Cheers,
>
> Peter.
>
> Dennis Reedy (JIRA) wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>> ]
>> Dennis Reedy commented on RIVER-317:
>> ------------------------------------
>>
>> I dont see how the -dl.jar files are being handled with this approach. How
>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>> With River services we have multiple artifacts per service, an
>> implementation jar, a download (client) jar and potentially a service ui
>> jar.
>> I suggest that we need to be thinking of adding classifiers for the
>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>
>> Declaring dependencies on River produced maven artifacts need to account
>> for how a maven project will use the artifacts.
>>
>>>
>>> Deploy Apache River artifacts to Maven repositories (both release and
>>> snapshot)
>>>
>>> -------------------------------------------------------------------------------
>>>
>>> Key: RIVER-317
>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>> Project: River
>>> Issue Type: Task
>>> Components: Web site and infrastructure
>>> Affects Versions: AR2, AR3
>>> Reporter: Jeff Ramsdale
>>> Fix For: AR2
>>>
>>> Attachments: river-poms.patch
>>>
>>>
>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>> repository upon release. It would be even better if snapshot builds were
>>> also deployed to a snapshot repository by Hudson.
>>> See thread:
>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>
>>
>>
>
>