creating a branch

There does not seem to be any need for a further release of the NET
1.x line, which is currently the trunk version, so I propose to:

* rename trunk as branches/NET_1_x
* rename branches/NET_2_0 as trunk

Any objections?

Pig Developers,

 

I would like to propose that we branch for Pig 0.8.0 at the end of
August and plan for the release by the end of October. Please, let me
know if you see problem with either of the dates.

 

If you are planning to contribute any patches to Pig 0.8.0, please, make
sure that you have a JIRA open and linked to 0.8.0 release and also that
you will be able to get the code in before the branch is created. If you
have a JIRA assigned to you that is linked to Pig 0.8.0 and you don't
think you can get it in before the branch, please, unlink it from the
release.

 

Thanks,

 

Olga

Hello,

I just created a build job for the 10.6 branch in Hudson [1].
I also added a note for this under "Prepare the community for a new 
release" in DerbySnapshotOrRelease [2]. This is only necessary for new 
major releases, where we actually create a new branch.


Regards,


[1] http://hudson.zones.apache.org/hudson/job/Derby-branch-10.6/
[2] 
http://wiki.apache.org/db-derby/Derby...for_a_new_release

Just saw these two fail on a regression run on the 10.6 branch.

derbyall/derbynetclientmats/derbynetmats.fail:derbynet/testProtocol.java

< PASSED
148a148,149
 FAILED - Expecting sqlCode 0 got ffffffff in line 1475
 java.lang.Exception

etc.



derbyall/derbynetmats/derbynetmats.fail:lang/ShutdownDatabase.java
Salient part of diff seems to be:
 com.ibm.db2.jcc.c.DisconnectException: The application server
 rejected establishment of the connection.  An attempt was made to
 access a database, testOnlyTransactionWasCommitedDB;shutdown=true,
 which was not found.

Searched, but couldn't find likely open issues. Anybody else seen those?

I also saw one of the replication tests fail on a fork "not enough
space", using the same setting I have used previously for suitesAll.

-client -Xms128M -Xmx512M -XX:MaxPermSize=128m

but maybe that is no longer sufficient?

Dag

We should change the 2.2 build JDK from 6 to 5 because we can't start the
server with jdk 5 if we build 2.2 branch with jdk 6.  See [1] for more
background.

Jarek,

I remember that you are owner of the geronimo build system.  Can you help
do
that ?


[1]https://issues.apache.org/jira/browse/GERONIMO-5369

Hi Eshan,

I've just had a quick review of the staging branch. It looks close to
working for the file merge. It would be good to move forward soon because
there's many other things to do! :)

We've been going around a few alternatives for the API, and I think it
would be good to clean it up and finalise it.

These are the current issues in the code I think need cleaning up:
- there's a lot of use of fields - but the classes are only instantiated
once by Spring. This means they aren't thread-safe, and overly complicated
to work with (for example, the setters calling other setters). The
operations don't need any state since they are meant to be done in one go,
so the data can be passed to the merge() method
- the test code is running inside src/ instead of target/ - this means the
source code gets changed (and these changes appear in patches...). Also,
the test artifacts added to the test repository are a bit confusing - since
o.a.archiva:archiva is a POM, there shouldn't be JARs. I suggest creating
new artifacts for merging tests and not modifying the existing
maven2-repository test.
- the SourceArtifacts class is now redundant (calling
metadataRepository.getArtifacts(repo) can be used instead)
- the old archiva-repository-layer API should not be used (except for the
RepositoryMetadataMerge class). Use the methods from maven2-repository and
metadata-model instead. Never use ArchivaArtifact! :) There's a lot of
manually constructing Maven information, even though the APIs are available
already - eg RepositoryPathTranslator.

Here is what I think needs to be done to get the merging API complete
based on the previous thread:

First, create an org.apache.archiva.repository.staging.RepositoryMerger
interface, which is the external interface for those wishing to merge
repositories (in our case, used from the web application). Probably it has
these methods:

void merge( String sourceRepoId, String targetRepoId );
void merge( String sourceRepoId, String targetRepoId,
Filter<ArtifactMetadata> filter );

The filter could be called with "new IncludesFilter( listOfArtifacts )" to
merge a given list of artifacts, similar to the current lists passed into
the ArtifactsMerger.

Second, change ArtifactsMerger to
org.apache.archiva.repository.staging.Maven2RepositoryMerger and implement
the RepositoryMerger interface. Move the code from doMerge into here.

Finally, clean up the code following the comments above.

After this is done, I think the implementation on the wiki should be made
more detailed, breaking it down to the tasks remaining, in order, with each
able to be completed in roughly a week.

Does that sound like a good plan?

Thanks,
Brett

Hi, Kevan:

 From openejb subversion log:
http://svn.apache.org/viewvc?view=rev...p;revision=962759, you
already
merge serveral fixes and some code from openejb trunk, all merge work is
already finished ?coz now i built openejb 3.1.3 latest code in my local
and
then build geornimo 2.2.2 but server failed to start coz mejb error. Here
just confirm it to exclude code merge problem. Thanks in advance!

Hi,

Coming back to the SLING-1603 discussion, I have progressed on the
contrib/extensions/bgservlets implementation and the API as defined in
the SLING-1603-engine works for me.

I also chatted with Victor Saar who says he's been using it
successfully in a different context, calling the SlingServlet service
programatically.

At this point I would suggest merging the SLING-1603-engine branch
into bundles/engine. Utility request/response classes are available in
the bgservlets bundle [1], we might want to move those elsewhere (a
new commons/http bundle?), but that can be later.

The SlingServlet interface can be found at [2] and the other changes
in the engine bundle is just the addition of the processRequest method
to the SlingMainServlet [3]. So the impact on the bundle engine's
public API is only the addition of the SlingServlet service.

Do people agree with this engine API addition?

-Bertrand

[1]
http://svn.apache.org/repos/asf/sling...sling/bgservlets/

[2]
http://svn.apache.org/repos/asf/sling...SlingServlet.java

[3]
http://svn.apache.org/repos/asf/sling...gMainServlet.java

Hi,

after a very long time Gump has started to build larger parts of Cocoon
again and we've run into an issue.  Cocoon's expression language uses
JEXL 1.x and in Gump it builds against the the 1.x svn branch of JEXL.

Unfortunately the VelPropertyGet interface inside that branch contains a
method that is new when compared to JEXL 1.1

<http://vmgump.apache.org/gump/public/...age-impl.html>

A quick scan revealed the isAlive method has been introduced as part of
JEXL-13 <https://issues.apache.org/jira/browse/JEXL-13> in svn
revision
543702
<http://svn.apache.org/viewvc/commons/...amp;r2=543702>
more than three years ago.

JEXL-13 claims 2.0.1 was the release to incorporate the fix, so to me it
looks as if the patch should have never been applied to the 1.x branch.
My suggestion would be to revert JEXL-13 from the branch, but then again
I'm neither familiar with JEXL nor Cocoon's usage of it.

If reverting the patch seems to be a bad idea, what would the JEXL
developers recommend to the Cocoon developers going forward?  I'm not
sure whether migrating Cocoon to JEXL 2.x would be an option.

Stefan

Update version number to 2.1.6 for 21 branch

See
<http://hudson.zones.apache.org/hudson...0.6/5/changes>

Refactor code for Geronimo 2.2.x branch

See <http://hudson.zones.apache.org/hudson...anch-10.6/10/>

I know we have commiters of these projects,  can anyone help apply the
patches in following JIRAs ?

1, https://issues.apache.org/activemq/browse/AMQ-2776   ,   this is opened
for GERONIMO-5371
2, https://issues.apache.org/jira/browse/OPENEJB-1308 , for tck
3, https://issues.apache.org/jira/browse/OPENEJB-1299, for tck
4, https://issues.apache.org/jira/browse/AXIS2-4751, for tck, It was fixed
by Jarek but now is reverted by other AXIS2 committer.

<https://issues.apache.org/activemq/browse/AMQ-2776>

Repositories page is broken in MRM-980 branch

On 06/01/2010 09:21 AM, ham### @apache.org wrote:
 AVRO-496. python sample_http_client.py is broken (Jeff Hodges via
hammer)


 Modified:
      avro/branches/branch-1.3/CHANGES.txt
      avro/branches/branch-1.3/lang/py/test/sample_http_client.py

When merging something from trunk you should indicate that in the commit 
message.  The commit message format used in Hadoop is, "Merge rXXX from 
trunk to branch-1.3.  Fixes AVRO-YYY."

Are you using 'svn merge' for these?  Since subversion 1.5 that should 
keep track of revisions done with 'svn merge', perhaps obviating the 
need to mention them in the commit message, but I see no 'svn mergeinfo' 
for the 1.3 branch, so I'm guessing you're not.

Also, you should update trunk's CHANGES.txt so that these changes show 
up in the 1.3.3 section there and no longer in the 1.4.0 section.

Doug

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

viola.lu updated GERONIMO-5349:

     [
https://issues.apache.org/jira/browse...nels:all-tabpanel
]

viola.lu closed GERONIMO-5349.

Hi,

I am trying to create a new rule, which can be defined in xml-rule file
also. The rule is extension to the existing call-param-rule in which we
can
pass the constant parameters (mainly string constants) which is currently
not possible with the call-param-rule.
After googleing I found the steps to do it which are:


   - Update the DTD. You should add an element type for your rule. The
   element should have an attribute corresponding to each of the rule's
   initialization parameters.
   - Define an ObjectCreationFactory
   - Extend DigesterRuleParser , and override the addRuleInstances()
method
   to add the rules for parsing your new element.

I did all the three steps but still I am not able to call the method with
string constants which I am defining in the rule-xml. I am getting the
values of parameter as null.

Attachments:
*digester-rules.dtd* (This is the updated dtd with the new element added
as
call-constant-param-rule. So step 1 is done.
*UpdatedRuleParser.java* (This java file defines the ObjectCreationFactory
(ConstantParamRuleFactory) and also extends the DigesterRuleParser.
*_xelerator_config_rule.xml* (XML file which defines the digester rules).
*_xelerator_config.xml *(XML document which needs to be parsed).
*ConstantParamRule.java* (Extended rule file)

What is it which i am missing or doing wrong.

Thanks in advance.

--wadi

Hi,

I am trying to create a file from server side following some examples, but
no way, the file is not created.
I have had a look to server logs but I don't find any error and the source
code is not throwing anything. 

Here the piece of code:
            Node root = session.getRootNode();
            Node userRoute=root.getNode("content/myProjectNode");
            
            Node fileNode = userRoute.addNode("myFile.gpx", "nt:file"); 
            Node resNode = fileNode.addNode("jcr:content", "nt:resource");


            resNode.setProperty("jcr:mimeType", "text/xml"); 
            resNode.setProperty("jcr:encoding", "UTF-8");
           
resNode.setProperty("jcr:lastModified",Calendar.getInstance().getTimeInMillis());

            resNode.setProperty("jcr:data",new
ByteArrayInputStream(myString.getBytes()) );

Does anybody find something wrong?

Thanks in advance,

Audrey